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?
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
Related
What's the best practice to control versions of Tableau projects?
If a change in Tableau project requires changes in the database (in my case - RedShift) and in ETL (in my case my python script), how to version control all of them together, such that I would be able to roll-back to previous version in case of a problem?
Thanks!
EDIT - Tableau has added version control features to Tableau Server since the time that this answer was originally provided.
At present Tableau Server does not provide version control functionality. There are a few ideas on the Tableau Community forum requesting integration with version control software such as Git or for version control to be baked into Tableau Server. Since Tableau workbooks are just XML files, then one could use some form of source control software for workbooks stored on a shared drive, and for publishing permissions to be restricted to a site/project admin
In theory a script could tie all of these components together. If a particular version of a Tableau workbook were associated with a specific database and ETL change (although I'm not sure what part the Python script plays here), then the previous version of the workbook could be retrieved from source control and republished as part of a rollback
Another way to accomplish the ability to rollback to previous version, is to run the native Tableau backup command just before applying any project changes. This will provide a snapshot of the server state at the time of the change.
The format is tabadmin backup backupfilename
In Tableau 8.0 and earlier, the server must be stopped first, via tabadmin stop
So your existing DB and ETL change deployment mechanism could be extended to call the backup command, and use a backupfilename that has the build or release number appended in the filename.
Running a server backup like this may not be as heavyweight an operation as you think- if your workbooks use all live connections and no cached or uploaded data, the backup command is quick and should complete in several seconds.
I'm working on creating a deploy script to migrate new development from our dev server to our uat server. Unfortunately, the devs that made the changes didn't script them out at they coded. The easiest way for me to approach this is to use SqlDeveloper's database diff functionality. It does a good job of highlighting the differences and creating a script that I can run on UAT. However, I've noticed that it doesn't take into account any dependencies. For example, a it will put a command to create a table below a table that references it in a foreign key constraint. Because the referenced table doesn't exist yet, the first table create command fails. I've seen this with views referencing packages, packages referencing packages, etc. Is there any easy to way either 1) force sql to export in a "smarter" order or 2) manually calculate the dependencies (ex: querying USER_DEPENDENCIES, etc) so that i can manually sort the file of create commands without resorting to trial and error? I guess we could consider purchasing a commercial product as long as it matched exactly what we are looking for.
Note: we will probably have to deploy to UAT multiple times in order to support testing by end-users. I am trying to automate this as much as possible so I don't have to manually recreate this script every single time!
Thanks!
EDITED: from original as frankly it was a poor question first time around....
We have a batch script called DEV.DBDeployment.DropCustomCreate.bat, as the name suggests this drops and creates our db from a fresh, a useful tool in Dev but we don't always want to drop the database, sometimes just get the latest changes.
It's worth noting currently every CI checkin triggers a build in TeamCity which pumps the current Major.Minor.BuildNumber.Revision (e.g. 1.0.123.1568) number in to all AssemblyInfo.cs files within all Visual Studio projects. This obviously allows us to stamp the resultant dll's with the build number, pretty standard stuff for sure. We also overwrite a BuildInfo.txt file in a similar way, most importantly this BuildInfo.txt file is included within every deployment package and sits within the RoundhousE\deployment folder and is referenced by /vf=%version.file% when we run rh.exe as mentioned above from the .bat file. So we're sorted for deploying to existing databases in Test and Prod.
However in dev the AssemblyVersion is always 0.0.0.0 in AssemblyInfo.cs, as is the version number in BuildInfo.txt, therefore how do devs stage their changes locally against their database. For example, with this setup when we run rh.exe all changes will be stamped with the version number 0.0.0.0. Is the expectation that in dev you will always drop and create? If that's the case I'm assuming we need TeamCity to checkin the BuildInfo.txt file so RoundhousE can reference it from source control when executed in dev?
Is there something I'm missing here?
I think we discussed this over here - https://github.com/chucknorris/roundhouse/issues/113
As you saying about the .bat file; that is a tool for roundhouse. You have to run that batch file again and again when you want to run your scripts. If you want to run scripts when you build the roundhouse database project then you have to configure that with certain steps. If you wish I can tell you if you replied.
I have developed a Joomla extension and in the newest version the need to delete one column from a table belonging to my plugin has arisen.
As far as I know there is no easy way to delete a column in Mysql only if it exists. Therefore, the only possibility I see at the moment to achieve that, would be to use custom php upgrade code, as shown here.
But this problem would seem so common to me, that I would suspect to be an easier solution?
Is there maybe an easy way (provided through Joomla) to execute a schema change only when updating from a particular extension version?
Check Managing Component Updates with Joomla; starting with Joomla 1.6 there is a defined way to execute specific SQL instructions for an upgrade from one version to another. Basically, for each version an SQL file has to be created (even if it's empty or only contains comments) in a specific file structure. The linked article explains the details.
in our company we use tfs for source control of sql database version,when developers change the database they generate Equivalent script and put it in sql tfs project and checked in it with related workItem.after build we generate patch with this script for clients,but before pacth we need to some one decide on priority of checked in script,now i want to this decition become automatic and my question is how could specified priority in the moment of check in?
Sorry for my bad english,if you want more informationn to answer let me know.thanks.
Version handling of databases seems to be a never-ending problem. At a previous client, we gave the databases version properties, and then stored patch scripts in folders for each version, e.g. "Patches/2.0.10", "Patches/2.1.0". The patch scripts could then be executed in the same order as they were checked in (creation date).
Upon release, we ended up generating a complete patch script consisting of all those separate patches merged together (since the patches often affected the same data, they could be optimized) along with a new version number, allowing us to record what version any given databes instance had.