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 <[email protected]> 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 > [email protected] > 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/ >
_______________________________________________ Koha-devel mailing list [email protected] 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/
