Ind Posted August 18, 2012 Posted August 18, 2012 Current: convert_engine_innodb.sql convert_engine_myisam.sql convert_passwords.sql item_db.sql item_db2.sql item_db_re.sql logs.sql main.sql mob_db.sql mob_db2.sql mob_db_re.sql mob_skill_db.sql mob_skill_db2.sql mob_skill_db_re.sql upgrade_svn10575_db.sql upgrade_svn10575_log.sql upgrade_svn10580.sql upgrade_svn11018.sql upgrade_svn11106.sql upgrade_svn11388.sql upgrade_svn11548.sql upgrade_svn11582.sql upgrade_svn11721_log.sql upgrade_svn11895.sql upgrade_svn11915.sql upgrade_svn12043.sql upgrade_svn12278.sql upgrade_svn12294.sql upgrade_svn12368.sql upgrade_svn12464.sql upgrade_svn12559.sql upgrade_svn12561.sql upgrade_svn12581.sql upgrade_svn12725.sql upgrade_svn12975.sql upgrade_svn12975_log.sql upgrade_svn12975_view.sql upgrade_svn13025_log.sql upgrade_svn13115_mercenary.sql upgrade_svn13117_char.sql upgrade_svn13166_mercenary_owner.sql upgrade_svn13370_inventory.sql upgrade_svn13390.sql upgrade_svn13541.sql upgrade_svn13583.sql upgrade_svn13719.sql upgrade_svn13881.sql upgrade_svn13890.sql upgrade_svn13960_questlog.sql upgrade_svn13963.sql upgrade_svn14036.sql upgrade_svn14085.sql upgrade_svn14242.sql upgrade_svn14507.sql upgrade_svn14579.sql upgrade_svn14672.sql upgrade_svn14700.sql upgrade_svn14713_log.sql upgrade_svn14759.sql upgrade_svn14796.sql upgrade_svn14797.sql upgrade_svn15003.sql upgrade_svn15420_log.sql upgrade_svn15519_log.sql upgrade_svn15531_db.sql upgrade_svn15572.sql upgrade_svn15818_log.sql upgrade_svn15885.sql upgrade_svn15926_log.sql upgrade_svn16490.sql upgrade_svn16518.sql upgrade_svn16639.sql upgrade_svn16645.sql upgrade_svn16663.sql Proposal: item_db.sql item_db2.sql item_db_re.sql logs.sql main.sql mob_db.sql mob_db2.sql mob_db_re.sql mob_skill_db.sql mob_skill_db2.sql mob_skill_db_re.sql tools/convert_engine_innodb.sql convert_engine_myisam.sql convert_passwords.sql [*]upgrades/ upgrade_svn10575_db.sql upgrade_svn10575_log.sql upgrade_svn10580.sql upgrade_svn11018.sql upgrade_svn11106.sql upgrade_svn11388.sql upgrade_svn11548.sql upgrade_svn11582.sql upgrade_svn11721_log.sql upgrade_svn11895.sql upgrade_svn11915.sql upgrade_svn12043.sql upgrade_svn12278.sql upgrade_svn12294.sql upgrade_svn12368.sql upgrade_svn12464.sql upgrade_svn12559.sql upgrade_svn12561.sql upgrade_svn12581.sql upgrade_svn12725.sql upgrade_svn12975.sql upgrade_svn12975_log.sql upgrade_svn12975_view.sql upgrade_svn13025_log.sql upgrade_svn13115_mercenary.sql upgrade_svn13117_char.sql upgrade_svn13166_mercenary_owner.sql upgrade_svn13370_inventory.sql upgrade_svn13390.sql upgrade_svn13541.sql upgrade_svn13583.sql upgrade_svn13719.sql upgrade_svn13881.sql upgrade_svn13890.sql upgrade_svn13960_questlog.sql upgrade_svn13963.sql upgrade_svn14036.sql upgrade_svn14085.sql upgrade_svn14242.sql upgrade_svn14507.sql upgrade_svn14579.sql upgrade_svn14672.sql upgrade_svn14700.sql upgrade_svn14713_log.sql upgrade_svn14759.sql upgrade_svn14796.sql upgrade_svn14797.sql upgrade_svn15003.sql upgrade_svn15420_log.sql upgrade_svn15519_log.sql upgrade_svn15531_db.sql upgrade_svn15572.sql upgrade_svn15818_log.sql upgrade_svn15885.sql upgrade_svn15926_log.sql upgrade_svn16490.sql upgrade_svn16518.sql upgrade_svn16639.sql upgrade_svn16645.sql upgrade_svn16663.sql please share all your thoughts. thank you for your time. 4
xazax Posted August 18, 2012 Posted August 18, 2012 If we restructure our database layout we should also make the tables versioned. And the server would throw a warning if there is an outdated table ( somebody forgot to apply the upgrade sql files ). Anyways I think we can purge the really old SQL upgrade files.
Ind Posted August 18, 2012 Author Posted August 18, 2012 If we restructure our database layout we should also make the tables versioned.And the server would throw a warning if there is an outdated table ( somebody forgot to apply the upgrade sql files ). how'd you have it checked? Anyways I think we can purge the really old SQL upgrade files. we could create a policy e.g. upgrade files are kept for a range of y revisions (if anyone wants older for whatever reason they can use trac or checkout a older revision of the sql-files folder)
xazax Posted August 18, 2012 Posted August 18, 2012 I don't know if there is a method to make tables versioned, but a primitive way to implement something like that is: have a version table with a version field, one integer. On each database change, the upgrade file bump the version, and of course we also bump te version in main.sql, and in the server there could be a #define that also needs to be bumped, and we can check if those versions are the same. Probably there are some better methods, I'm not experienced with SQL.
Euphy Posted August 20, 2012 Posted August 20, 2012 +1 I think all the SQL upgrades pre-rAthena should be removed. 3
Kenpachi Posted August 20, 2012 Posted August 20, 2012 I don't know if there is a method to make tables versioned, but a primitive way to implement something like that is: have a version table with a version field, one integer. On each database change, the upgrade file bump the version, and of course we also bump te version in main.sql, and in the server there could be a #define that also needs to be bumped, and we can check if those versions are the same. Probably there are some better methods, I'm not experienced with SQL. AFAIK there is no good solution to version tables. Actually it's not required since the map server will throw an error if the DB layout doesn't match with what he tries to do. I think all the SQL upgrades pre-rAthena should be removed. +1
Brian Posted August 20, 2012 Posted August 20, 2012 Another way, similar to what FluxCP uses: - start with a base revision for main.sql - every future change is done in an upgrade_svn file (main.sql is not edited) - when the server successfully installs an upgrade, it touches a blank file to keep track of which upgrades have been installed (or we could track this in a SQL table that stores version numbers) * Optional: main.sql could be split so each CREATE TABLE is in a separate file (FluxCP example) Then the install process is: - execute main.sql AND execute all upgrade files since main.sql was last based 2
Kenpachi Posted August 20, 2012 Posted August 20, 2012 Then the install process is: - execute main.sql AND execute all upgrade files since main.sql was last based I'd never use a software which makes so much work just for installing it...
Brian Posted August 20, 2012 Posted August 20, 2012 but this example would be fully automated! as long as the MySQL users they define in inter_athena.conf has all the CREATE, ALTER, SELECT, INSERT, UPDATE, and DELETE privileges
GreenBox Posted August 20, 2012 Posted August 20, 2012 This is like RoR track the db updates, very simple and useful.
Ind Posted September 6, 2012 Author Posted September 6, 2012 the updater discussion has delayed this topic, so I'm moving on with the topic's original goal and we can create a new one solely for the updater discussion. Added this in r16750 1
Recommended Posts