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 <mdha...@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 > _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
