[Koha-devel] Bug 7167 New updatedatabase

[Marcel de Rooy]

Thanks your feedback until now! 
I tend to agree more with Mason here. If Paul adjusts his patch to meet QA, let's move forward with that patch. Adding the REVERT logic would make it even better later on. 

To get the discussion further, I think we still need two answers: 
1) Should we add the distinction between numbered approved dbrevs and unnumbered ones in testing stage that I suggested in my QA comments?
2) As Jared suggested, should we leave enabling the development mode of this feature in an environment variable (DEBUG, set in Apache conf)? 

Marcel

________________________________________
Van: koha-devel-bounces at lists.koha-community.org [koha-devel-bounces at lists.koha-community.org] namens Mason James [mtj at kohaaloha.com]
Verzonden: zaterdag 16 juni 2012 5:37
To: Ian Walls
Cc: koha-devel at lists.koha-community.org
Onderwerp: Re: [Koha-devel] Bug 7167 New updatedatabase

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