[Koha-devel] How about a different way of handling database updates

[Kyle Hall]

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 at 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 at lists.koha.org
> http://lists.koha.org/mailman/listinfo/koha-devel
>