Db Migration

Discussion in 'Extensions' started by majid1f, Aug 26, 2018.

  1. majid1f

    majid1f Member

    Joined:
    Feb 23, 2015
    Messages:
    113
    Likes Received:
    19
    hi,
    what can I do for updating db in my extensions? I see MW core and see MW has been created a separate SQL file for each version of MW core and for update worker MW used the current version which stored in DB and compare to version in file, and run DB queries, (as I understood), now what should i do in the my extensions? (i see checkUpdate() and update() methods in the ExtensionInit file)

    another question, why MW don't use Yii DB migration strategy for updating DB?
     
    Last edited: Aug 26, 2018
  2. frm.mwz

    frm.mwz Well-Known Member

    Joined:
    Mar 8, 2016
    Messages:
    3,705
    Likes Received:
    676
    S.E:
    2019-11-27 02:17:39
    L.T:
    Regular
    L.C:
    7
    If there are changes in the database from one MailWizz version to the next (see update databases sql files), one can update extensions if need be.
     
  3. majid1f

    majid1f Member

    Joined:
    Feb 23, 2015
    Messages:
    113
    Likes Received:
    19
    i mean my own extensions which i developed, how can i update my added tables? for install i added install.php and then run it in before enable method of the extension page and for delete in same way, but now for update, what should i do?
     
    Last edited: Aug 26, 2018
  4. twisted1919

    twisted1919 Administrator Staff Member

    Joined:
    Dec 27, 2014
    Messages:
    10,125
    Likes Received:
    2,352
    @majid1f - extensions upgrade for database should be handled by yourself, for example you can use $this->setOption() and $this->getOption() to set and get options for your extension, and then compare these and if needed be, run the extension update sql.
    You should know that the update method is called only when your extension version number changes.

    There's no real reason, at the time of deciding how to handle upgrades, we decided to roll our own workers instead of migrations because most of the time we had additional work to do in the workers, not just database changes.
     
    majid1f likes this.

Share This Page