I like this idea. I've had a number of problems with the current system. If I understand correctly, we would need a database table to track updates. It sounds like we would only need a single column that would contain the title of the update, say "BugFix2235" for example. The update script would then check the db_revisions table to see if "BugFix2235" is in there. If not, it would execute the update and add "BugFix2235" to the db_revisions table. We could also continue updating the Version pref like we have been.
Also, in order to keep the table from being huge, the release maintainer will occasionally announce a database revision. We will keep the number to effectively federate the updates. Within each revision there will be any number of update strings. With each new revision it is assumed that the updates from the previous version are applied, so the database table is emptied.
This part does not sound necessary to myself. We could just keep the existing updatedatabase.pl and just add a new sub to handle the new system, and continue on with it. Kyle http://www.kylehall.info Information Technology Crawford County Federated Library System ( http://www.ccfls.org ) On Wed, Jan 27, 2010 at 6:28 PM, Michael Hafen <mdhafen@tech.washk12.org> wrote:
Database updates using the updatedatabase.pl script. I'm thinking there could be a better way, both for developers and the release maintainers.
The problem is that we have a sequential number controlling the updates. This is working now, but I think there could be a better way. The current method is simple, it has that benefit. On the other hand it makes things more complex for the release maintainer to make sure the sequence is right. It's also more complex for the developers to coordinate who will use what number.
My idea is to use a string for the update instead of a number. It will mean adding a table to the database to track update strings that have been applied. This way each developer, or company, uses their own string to distinguish updates.
Also, in order to keep the table from being huge, the release maintainer will occasionally announce a database revision. We will keep the number to effectively federate the updates. Within each revision there will be any number of update strings. With each new revision it is assumed that the updates from the previous version are applied, so the database table is emptied.
There will be some added complexity when when there is a revision. The developers who are working on update code will have to move their in the updatedatabase.pl file into the section for the new revision.
The added benefit of this method is that developers, and companies, can have a database update easily without worrying about it getting into the official code repositories. The change is kept in the developers own branch, with it's unique update string, while others that are accepted into the official code are also there.
Does that make sense? Have I described it well enough? Is anyone interested in this idea?
I've been thinking about it, and the changes to the database update process should be minimal. There will be significant changes, but not many of them. There will have to be a sub added to check if an update string is in the database. And a sub to add the update string to the tracking table in the database. And the revision update sub will have to be expanded to empty that table. I think that would be the extent of the changes.
Comments please.
-- Michael Hafen Systems Analyst and Programmer Washington County School District Utah, USA
for Koha checkout http://development.washk12.org/gitweb/ or git://development.washk12.org/koha
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel