From: Louis-Philippe H. <lph...@dr...> - 2008-08-17 23:30:25
|
Hello, I consider one of the major issues that make tikiwiki hard to update and hard to make changes to at this time is that the database update script is linear, re-entrant and limited to SQL. It does not allow us to make the necessary data conversions when they are needed. Category permission changes in 2.0 are a good example of this. The way I typically deal with these issues is to have a PHP script to check the database version stored in a table, apply the necessary patches and update the version number again. The patches also contain hooks to execute code before and after the database patching occurs, which allows to run custom code and do the necessary conversions. The model works great when you basically have changes only in a single branch as the version number is incremental. While I don't expect many changes to the database in stable branches, experimental branches and custom code may need something more powerful to be handled properly. Although I can't find the reference anymore, I have seen a technique using a schema change table where basically every patch that was ever applied is logged. The script would then verify if the missing patches and apply them. Something like this would simplify the patches as we wouldn't have to rely on ignoring previous errors. However, it will change the way updates to the database are made and applied. Rather than commit to a single file every time, it will be necessary to add a new file. As far as updating go, it can be nearly transparent to the tiki-install.php users, but will require PHP CLI for shell use as the logic will be slightly more complex to apply. Ideally, it could be built to run additional scripts during updates as well. I am likely to work on this during the next few days in an experimental branch. Is there anything that you found annoying in the tikiwiki update process so I can consider it along the way? -- LP |