[RFC] Migrations

[MichaelC]

What happens when an extension logs data to a log using a language variable, then the extension is disabled. Will it remove the log entries (I'm guessing not). So there needs to be a way to be able to add instructions that are specific to un-installing (allowing it to remove any data it has added to other tables it did not add).

When it's disabled, no it shouldn't remove the log entries. And for that, I think we could keep it looking through the extension's language directory, perhaps. But when an extension is purged, it should remove related log entries (although really that's up to the extension author to implement, I think?).

Maybe if a language file called always_include.php existed it would always be included, whether the extension was enabled or disabled? The purge would remove language entries but yes, thats why I suggested allowing uninstall instructions which will only run when its un-installing, not installing.

[Oleg]

In the specific case of logs I think it is acceptable to leave unsubstituted language strings in log entries. Admins should understand what happened there, if they are bothered by that they can clear the logs. Until someone complains about this I wouldn't worry too much about it.

[brunoais]

I think there should be a checkbox that allows filtering the kind of messages the user wants. This way the admin can see only what he wants without the extra stuff he might not be interested at that moment.

[MichaelC]

I think there should be a checkbox that allows filtering the kind of messages the user wants. This way the admin can see only what he wants without the extra stuff he might not be interested at that moment.

How are PMs to do with Migrations?

[brunoais]

^ I was answering to Oleg

[naderman]

I agree with Oleg, logs should just remain, and language isn't really a concern. Clear the logs if you don't want to see the bare strings, otherwise ignore them.

[MichaelC]

What would be the install file for extensions? Would it be something similar to the UMIF files in olympus or would it be an .sql file?

[A_Jelly_Doughnut]

Needs to be something that is cross-database friendly (so not raw SQL)

[igorw]

Similar to UMIL/db_tools.

[Oleg]

Migrations probably should use db_tools, and if anything is in umil and not in db_tools it should be added to db_tools.