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