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

[Michael Hafen]

Clearing the tracking table isn't necessary.  I'm thinking 50 versions
down the road when the tracking table has some 500 strings.  This makes
it a little harder to ensure a unique string for the update.  And I
would rather the table stay small to be quicker to index and to take up
less space on the database server.  Since it's just the one string,
which has to be unique anyway, this is a very insignificant concern.

My thoughts on the title of the update though are a little different
from your example.  I'll explain here so you all know what I'm thinking.
I think an example would best illustrate.  If it were the title of one
of my updates it might be 'mdhafen.001' or 'wcsd.3_0_0.001'.  Or maybe
even 'wcsd.mdhafen.001'.  I'm just beginning to think of the details of
the title scheme.  I think that third example is what I'll end up with.
For Kyle perhaps the title would be 'ccfls.kyle_m_hall.001'.  So that's
what I'm thinking; that should make it easy to have unique update
titles.

Comments?

On Thu, 2010-01-28 at 07:51 -0500, Kyle Hall wrote:
> 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 )
> 
> 
> 
> 


-- 
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