Looking for complete sample of upgradeTableDb and DBPREFIX_

[Een]

Ok, I'll give it a go and let you know how it goes.

[Een]

Long story short, a patch was needed on the studio to allow to test upgradeTableDb (because of the specific studio version that doesn't fit into the int type used for the global).

After patching I followed the procedure again, and it worked. So your upgradeTableDb is validated, and now the studio procedure works I have also updated the wiki to make it easier to follow.

So it should go well on your next deploy. Fingers crossed!

[MikeIsHere]

Thank you Een for all your work on this :fingers crossed:

[MikeIsHere]

It has seem to work -- thank you again

[Een]

It has seem to work -- thank you again

Great! Happy to know that.
Note: you may still want to have a condition matching the version number in the upgradeTableDb, to avoid having the sql inspection queries run each time you deploy a new version even if there has been no database change.

[Bids]

Hi,
I'm experiencing similar problems. I first uploaded a new version, but when I opened the existing tables, it gave me an error. I checked my code and I found the mistake. I followed all steps described before, I did the test in the studio and now everything is working fine in the studio. However, when I go back to my existing tables, some of them work (I think those that I opened with the intermediate version I uploaded) and some of them are not working. So now I went back to my previous stable alpha version.
How can it be that while all my existing tables are using the same stabel alpha version, there are only some of them working with my new version and some of them not? Can it be that for some of them the database has already been updated with an intermediate version? And if yes, how do I fix it? (I have also tried with checks for version <= 9999999999) .
Many thanks in advance!

[Tisaac]

Hi,
I'm experiencing similar problems. I first uploaded a new version, but when I opened the existing tables, it gave me an error. I checked my code and I found the mistake. I followed all steps described before, I did the test in the studio and now everything is working fine in the studio. However, when I go back to my existing tables, some of them work (I think those that I opened with the intermediate version I uploaded) and some of them are not working. So now I went back to my previous stable alpha version.
How can it be that while all my existing tables are using the same stabel alpha version, there are only some of them working with my new version and some of them not? Can it be that for some of them the database has already been updated with an intermediate version? And if yes, how do I fix it? (I have also tried with checks for version <= 9999999999) .
Many thanks in advance!

You can use this kind of trick to avoid error (much easier than checking for version if your db change is just adding a field for instance) :

Code: Select all

 
 $result = self::getUniqueValueFromDB("SHOW COLUMNS FROM `plan_validation` LIKE 'reshuffle'");
    if(is_null($result)){
      self::DbQuery("ALTER TABLE `plan_validation` ADD `reshuffle` BOOLEAN DEFAULT 0;");
    }

[Een]

Hi,
I'm experiencing similar problems. I first uploaded a new version, but when I opened the existing tables, it gave me an error. I checked my code and I found the mistake. I followed all steps described before, I did the test in the studio and now everything is working fine in the studio. However, when I go back to my existing tables, some of them work (I think those that I opened with the intermediate version I uploaded) and some of them are not working. So now I went back to my previous stable alpha version.
How can it be that while all my existing tables are using the same stabel alpha version, there are only some of them working with my new version and some of them not? Can it be that for some of them the database has already been updated with an intermediate version? And if yes, how do I fix it? (I have also tried with checks for version <= 9999999999) .
Many thanks in advance!

You can use this kind of trick to avoid error (much easier than checking for version if your db change is just adding a field for instance) :

Code: Select all

 
 $result = self::getUniqueValueFromDB("SHOW COLUMNS FROM `plan_validation` LIKE 'reshuffle'");
    if(is_null($result)){
      self::DbQuery("ALTER TABLE `plan_validation` ADD `reshuffle` BOOLEAN DEFAULT 0;");
    }

Yes. But you should still wrap it into an "if( $from_version <= prod_version_before_your_deploy ) so that it's run only once. Otherwise, it will be run for each http request of all versions of your game, and database inspection requests have a performance cost.

[Bids]

Thanks both of you! I will apply Tisaac's logic within the version logic and see if that helps. Because I understand Een's concern about the DB cost, totally makes sensse.
EDIT: It's still not working. I will look into tonight to see if I can understand why.

[Bids]

Hi,
I found the issue in the end. The database was already updated for some tables that I opened before after deploying a new verison, while others were not, while the still had the same 'from version'. So whatever I was trying now, I always had tables that were going wrong. In the end, because only 13 tables are running for my game, I just added a code that would add the missing column in any case, and I opened the 7 tables that were missing the extra column manually one by one. Once I knew the column was added to the database of that table, I uploaded a new version where it does not try to add a column anymore.
For new tables everything was always working fine.
Many thanks for your help.