On 2012-06-16, at 6:51 AM, Ian Walls wrote: > 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.
firstly, i love Ian's solution, i think its the ultimate solution for db-upgrades in Koha. (and i think most devs would agree?) i think we should accept Paul's patch, and plan to add Ian's 'DESCRIBE, CHECK, DO, UNDO' functionally to it, in a later patch Paul's solution is missing the ability to CHECK (and UNDO?) db-patches if we add those features to Paul's patch, we basically have Ian's solution, am i right here? surely this is the best way towards a solution here? rather than abandoning Paul's patch for a better patch, that does not yet exist
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ 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/
