[Koha-devel] Bug 7167 New updatedatabase

[Ian Walls]

Just bringing this back to original intent:  it's hard for developers and
testers to work with patches that have DB revs, so we want to fix that.
Basically, that means being able to easily tell what changes have been made
to the DB beyond the natural Koha progression.

The problem with the code we have, I think, is that we're trying to make
this something that can be managed in the staff client.  Our target
audience here isn't Koha users, it's testers and developers.  Whatever
we're doing to address our needs as code maintainers must not effect the
people actually using the software.

I've floated this before, so I will now again:  I think we need to move our
database updates to individual Perl files, with a set API: DESCRIBE, CHECK,
DO and UNDO.  If every atomic update contains the necessary logic to handle
these four functions, we'll be able to:

1.  see what the change is BEFORE applying it
2.  see if the change is necessary BEFORE applying it
3.  revert changes after testing them

updatedatabase, then, becomes the mechanism by which the RM assigns these
Perl files a linear sequence and distinct DB rev number.  Any change that's
running "on top" of the core Koha code won't need a temporary/fake number
assigned to it to get added.  Maintaining it will be the job of the
sysadmin who decided to run non-core code to begin with, but that's nothing
new.

It's very rare that sequence is important for DB revs, as we have few that
change the table structure, and those that do often do not interact in a
short span of time.  If you find a Koha DB rev doesn't apply to your
customized DB structure, it's time for a rebase!  I really don't think this
is a frequent enough occurrence to warrant too much consideration.

In short, I think we should hold off on our eagerness to push this change
through, and wait until we've come up with a different solution.  We're
only putting the users of Koha at risk for serious DB-related bugs, with no
tangible gain in it for them.

Cheers,


-Ian

On Fri, Jun 15, 2012 at 7:10 AM, Robin Sheat <robin at catalyst.net.nz> wrote:

> Op 13-06-12 15:39, Jared Camins-Esakov schreef:
> >     Development mode: Currently, you rely on $ENV{DEBUG} from koha-httpd
> >     file. I would turn this into a systempref. It is easier for
> >     developers to toggle it (compared to restarting httpd service).
> >
> > It's easier, but also a lot more dangerous in my opinion. The consensus
> > on the caching configuration was that it was too dangerous to allow
> > access to it in sysprefs. Based on that logic, I think using an
> > environment variable would be the way to go.
>
> My 2p right now is to agree with this, as someone who provides hosted
> Koha to people who don't necessarily know the ins-and-outs of it all, I
> can see having sysadminny-type options in the sysprefs in general
> causing issues.
>
> I'd advocate some standard for these kinds of things in the long
> term[0], but for the time being, I think an environment variable could
> work.
>
> Robin.
>
> [0] other examples I can think of that are impending: the filesystem
> location of custom XSLT and files that are attached to bib records but
> really live on the filesystem. These should be defined in a location
> that only a sysadmin can change them.
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120615/799800c1/attachment-0001.htm>