[Koha-devel] Bug 7167 New updatedatabase

[Mason James]

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 535 bytes
Desc: This is a digitally signed message part
URL: </pipermail/koha-devel/attachments/20120616/3f6a7d34/attachment.pgp>