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

[Michael Hafen]

I have an interesting idea about the system preference request in the
last point here.

Have the system preference editor create in the database a row for any
pref's it didn't find there.  It would have to keep track of what the
default value should be for all pref's though.

With the new system preference editor, as I understand it, changing the
text of a pref is changing a file instead of the database now, so that's
one of the two cases I can think of for a system preference to change
the database.

The other case is to create or delete a system preference.  Let's put
aside creating for a moment.  Thinking about deleting a pref, I might
argue that it shouldn't lightly be taken out of the database.  Currently
is is removed from the system preference editor, and ends up in the
Local Use category.  Maybe this category could be renamed 'Local Use /
Deprecated'.

The problem then becomes that the system preference editor isn't run
often enough.  So maybe there needs to be an addition to the version
check in Auth.pm.  Along with checking kohaversion.pl it could also
check something like 'sysprefs.pl' to make sure all officially supported
system preferences are in the database.  Then the update mechanism could
create the system preference instead while asking for it to be set ( if
the user doesn't want to use the default setting ).

That might be the way to go.  Have a 'sysprefs.pl' that checks the
database, and add to the update mechanism to create any that it reports
as not being there.  That way developers would be changing a file(s)
instead of the database.

On Wed, 2010-02-03 at 11:59 -0500, Galen Charlton wrote:
> Hi,
> 
> Quickly, from my point of view the main things I'd like to see in a
> revised database update system are:
> 
> * the ability to end up with a linear set of database updates in
> released versions, for the reasons Joe mentions
> * secondarily, the ability to have a linear path in HEAD
> * a reduction in purely textual merge conflicts - splitting up the
> monolithic updatedatabase.pl would go a long way to address this
> * a better way to manage database updates that are backported to the
> maintenance branch
> * a mechanism to allow a developer to readily renumber updates that
> they're working on in a topic branch when it comes time to submit to
> HEAD
> * getting simple system preference updates out of the main
> 
> Regards,
> 
> Galen


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