How to use custom SQL files with the TC update system?

Help and Support Help and Support
1

Hello,

I don’t understand how to use custom SQL queries in files in the /sql/custom/xxx folders in the right way.

Here’s an example of what I’m doing:

[ul][li]In Juli 2017 I start a complete new project and use TDB_full_world_335.63_2017_04_18.sql and all the stuff from git repository at this date.[/li]
[li]I commit to whole stuff in my own git repository.[/li]
[li]In Aug. 2017 I made some database modifications, create therefore some custom SQL files. I let do the core an automatic update as usual.[/li]
[li]I commit the custom SQLs in my own git repository.[/li]
[li]I do regular updates of TC 3.3.5 branch and merge them in my repository.[/li]
[li]In the meantime databases and table change their structures by different TC updates.[/li]
[li]In Spring 2018 Trinity is providing a new TDB_full_world_335.64_2018_02_19.sql[/li]
[/ul]
In June 2018 somebody else would like to start on another system a copy of our customized project.

[ul][li]He’s cloning the custom project from git repository and compiles it.[/li]
[li]At the updating process the core is asking for TDB_full_world_335.64_2018_02_19.sql[/li]
[li]After that (I guess) the core is applying outstanding TC updates and all the custom sql updates I made before.[/li]
[/ul]
But how can I prevent possible database conflicts between my sql queries in the custom updates I made in Aug. 2017 with the database structure of Spring 2018 ?

2

Good question. In the time back as I implemented the DB updater I thought about custom updates being compatible to the current database structure.

Currently there is no possibility to prevent such conflicts that you described as part of your question.

3

I found 2 very simple solutions:

Solution 1:

Change the name back to TDB_full_world_335.63_2017_04_18.sql (or whatever you have started once with the custom project). Thanks to the magic of programming of this wonderful updater the updates are processed in the right order.
The name of the full database is in revision_data.h.in.cmake .

Solution 2 (not tested):

Provide an own full world database file. As far as I have seen you need only to do all updates incl. custom updates into a clean database and than export it. Thanks to the table updates and its hashes the updater knows later what to do.

(Additionally you may also need to save a starting file with the db structure of auth and characters at the beginning of a custom project. Depends of what kind of custom sql queries you have.)