Best way to populate tables when upgrading plugins

Re: Best way to populate tables when upgrading plugins

by Ruben Cancho -
Number of replies: 0

Ok, I start to understand but still some doubts. I go topic by topic:

About automatic class loading,

In the Upgrade API docs says that the cache is reset before upgrade, so it's true that an autoloaded function could be missed in the cache during upgrade. I don't know how this cache works but I guess that calling a function in upgrade.php would require to generate part or all the cache again slowing down and and potentially timing out the upgrade. It's that correct? I was noticing a sluggish upgrade currently and maybe is because of this...

About libupgrade.php,

Thinking more on this I could include all Active Record classes there (require_once) and add the populate method there. So I could avoid the problem above.

About standard core functions and side effects,

I guess I should care that my Active Record classes only make calls to DB API and nothing more. It's correct?

About upgrade_XXXX_savepoint method,

This method I read that is like adding carabiners, and also reset timeout in between upgrade points to avoid them.

Separating in two steps the upgrade (structure and content upgrade) I potentially could have this calls:

// upgrade database structure
if (version > 1.0) { upgrade_XXXX_savepoint(true, 1.0, 'myplugin') }
if (version > 2.0) { upgrade_XXXX_savepoint(true, 2.0, 'myplugin') }
if (version > 3.0) { upgrade_XXXX_savepoint(true, 3.0, 'myplugin') }

// upgrade database content. From here all versions have the same schema vision and I think is safe to make calls
if (version > 1.1) { upgrade_XXXX_savepoint(true, 1.1, 'myplugin') }
if (version > 2.1) { upgrade_XXXX_savepoint(true, 2.1, 'myplugin') }
if (version > 3.1) { upgrade_XXXX_savepoint(true, 3.1, 'myplugin') }

Having this I don't understand if it will be possible to call upgrade_XXXX_savepoint in a non-incremental way. Here I would follow: 1.0, 2.0, 3.0, 1.1, 2.1, 3.1... Could be this a problem? Should avoid savepoint calls in the second section, and maybe only use upgrade_set_timeout() to avoid timeouts?

About what might happen in a few years time,

Yeah, this is my main concern. I know that a function that populate the database can change in the future to adapt to a new database structure. But updating the database structure before populating it I am trying to avoid this problem. If I don't miss something all versions should have the same database structure schema before populating database, so hopefully then I could finally reuse my functions and be happy again smile

Thanks for your answers,

Ruben.