CODEWITHSUNDEEP
joomlajoomla3.0
ttz
ttz

Reputation: 79

Update database on different environments in Joomla3.9 project

We are working on Joomla3.9 project, have different environments and are using git as vcs. So every developer works on is own branch. It would be nice to have a database compare function like in TYPO3 or Contao (see the database differences after updating the project and apply the database changes just by one click). Or like the laravel migration system.

Any developer should easily update his own lokal database after database changes where made due an extension update via backend or by another developer. And of course the staging or live system must be updated easily too. We don't want to execute sql-scripts with the changes in phpMyAdmin. We have tried https://dbv.vizuina.com/ . This is not the 100% solution. Like there is no cli support to start the migration process by an update script on the server.

Does anyone have a solution or knows an extension that can solve this problem? Or can this be handled with core Joomla functions (maybe with a little adjustment)?

So far, I've seen three possibilities to execute modifications to one ore many extension tables

1: Use the extension - revision control in the schema table. So add a new sql-file with an increased version number compared to the version number in the schema-table for this extension. Increase also the version in the manifest.xml and zip the extension again. Reinstall the extension via extension->manage->install. So the new sql-file with the increased version number will be executed.

2: like the point above, but install the extension via joomla update mechanism (update server).

3.: create a new sql-file in sql/folder of the extension. No version name is needed for the new file, just update.sql oder another filename. Execute this script in script.php in update()-method, after the extension is installed (in this case it's an update) again.

The third possibility might be interesting. It should be possible to trigger the update()-method with a cli command / function, so that the method can be triggered via a script on the server. But how can I get the info, which update-scripts have already been executed? Let's say I have 3 update files in sql-folder. update-1.sql, update-2.sql and update-3.sql. update-1.sql has already been executed. So I don't want to execute this sql-file again - only the other two. The schema-table is only used with the first two options. Do I have the info somewhere or must I manage the infos which update-scripts have been executed myself?

Upvotes: 2

Views: 150

Answers (1)

Marinos An
Marinos An

Reputation: 10858

The answer related to versioning database for extensions depends on whether these extensions are tightly coupled to the application or need to be reusable to other applications also.

The latter case normally means that each extension accesses its own custom tables, in which case you should keep separate versioning for the database than for the extensions.

  • App version history can be kept in a db_version table. Then an insert statement is added at the end of each update script (adding an incremental version number). e.g.

    insert into db_version(version,author,description) values(003,'Verna.Collins', 'removing obsolete column');

  • Provided that you need to apply data migration on extensions also, you need to maintain a db_version_extensions table which keeps version history for each of the extensions separately. e.g.

    '001' 'extension1','Mandy.Aguilar','initial version'
    '002' 'extension1','Mandy.Aguilar','adding extra column'
    '001' 'extension2','Edna.Potter','initial version'
    '002' 'extension2','Elvira.Townsend','dropping unused table'
    ..etc

Each extension zip should keep initial creation script and all sql-update files(which should normally not interfere with the rest of the app tables).

After pull it will be relatively easy to execute all the scripts with filename version greater than the last version number written in the database. This should be done for the app and for each extension separately.

Now if the extensions are tightly coupled to the app, it means that they might be using/updating tables of the app. For extensions of this type, you can add the updates as part of the application updates. These extensions could even be developed at the same repo, and be kept as directories instead of zip files.

Not sure if joomla supports any tools for automating the process of performing incremental db updates, but a nice tool is flyway, with ports for command-line, maven and graddle. See: how does flyway work

Upvotes: 2

Related Questions