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

Kyle Hall kyle.m.hall at gmail.com
Thu Jan 28 18:03:58 CET 2010


The naming convention sounds very reasonable. Very java import styled.
Very good idea.

Now the big question is, can we get any traction for such a big
change? Is there anyone else willing to comment on the possbility of
this idea?

Kyle

http://www.kylehall.info
Information Technology
Crawford County Federated Library System ( http://www.ccfls.org )




On Thu, Jan 28, 2010 at 10:46 AM, Michael Hafen
<mdhafen at tech.washk12.org> wrote:
> 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
>
>
>



More information about the Koha-devel mailing list