On Tue, May 24, 2011 at 9:12 AM, Paul Poulain <paul.poulain@biblibre.com> wrote:

Le 23/05/2011 14:48, Chris Nighswonger a écrit :

...

So my vote is to use this method unless there is a very compelling reason to do otherwise. What's happening with

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6328 (see comment 20)

So should I assume that "does not apply cleanly" in this case is due to the 'XXX' in the version number? If so, as I said, that is a 30 to 60 second fix. But without looking into it further, I'd guess that there were other problems with this patch set which caused it not to apply cleanly and that the DB version number was still only a less than one minute fix with the "other problems" (unrelated to the DB version number) being the real time consumer.

is interesting. I think the idea of atomic updates is very interesting. And the workflow/wiki must be updated anyway !

I agree that the wiki needs to speak with one tongue regarding whatever work flow is decided upon. :-) Kind Regards, Chris

I think the problem with database revision numbers comes down to something fundamentally structural. Database revision numbers are linear, and are part of the Koha version number. But our development is non-linear; using Git, we work off Directed Acyclic Graphs. There are multiple paths to reach the same destination. Trying to map the more complex DAG of our development down to a linear sequence is the source of this difficulty. So, what we need is to separate the mechanisms. What if we pulled out the database revision out of the version number, and used a hash of some kind to identify the current database structure? The hash could be calculated off the kohastructure.sql, which is where any structural conflicts would arise anyway. I think it'd be safe enough to ignore system preferences and other data, so long as the structure of all the database tables was factored in. This would allow us to apply patches with database revisions without getting 'out of order', as well as allow us to get to the same structure in multiple ways (like we can with code in Git). I suppose the difficulty here would be keeping kohastructure.sql synced with the database revision statements in updatedatabase.pl. Perhaps there's a way to just edit kohastructure.sql, then do a delta to generate the update statements required? Further thoughts? Am I missing something critical (I have this nagging feeling I am). -Ian On Wed, May 25, 2011 at 1:15 AM, LAURENT Henri-Damien <laurenthdl@alinto.com

wrote:

Le 23/05/2011 14:48, Chris Nighswonger a écrit :

...

Hi Paul,

On Mon, May 23, 2011 at 8:17 AM, Paul Poulain <paul.poulain@biblibre.com <mailto:paul.poulain@biblibre.com>> wrote:

Hi all,

I think there are some things unclear (at least for me ;-) ) about submitting bugs with DB changes.

<snip>

* we spoke of using XXXX in updatedatabase.pl <http://updatedatabase.pl> to have te RM pick the right number when needed.

Speaking from the prospective of Release Maintainer, this method works the most consistent for me. I have very few times when a DB update patch using the 3.NN.XXX format does not apply cleanly for me. This includes cases where NN == some subversion other than the current maintenance version. So with this, my workflow goes like this:

1. Apply patch/cherry pick. 2. Adjust rev number. 3. Commit rev number change. 4. Go on to the next patch.

On the rare occasion the original patch does not apply cleanly it takes all of about one minute to fixup.

So my vote is to use this method unless there is a very compelling reason to do otherwise. OK.

When you have something that should apply both to 3.2 and 3.4 (say an index change, or a change on a field (text to varchar or varchar to text or varchar 10 to varchar 255), you number that from which number ?) Do you keep the least number or do you use two different rev numbers ? If you keep both, when upgrading, you will have some unwanted issue raised. If you take the least, then the number of the revision in the master branch is not the correct one, and when ppl upgrade they either will loose some db changes or have duplicate numbers. It can be solved with a kind of "deduplication table". But rather uneasy to implement. Could be also solved with a variable that says... ok if you come from 3.2 then it is that number, 3.4 that other... But upgrade path will have to decide which path you are coming from.

I don't have THE solution.

I mean I had the problem with 3.0 to 3.2 and the "best way" (in terms of time/development/tests) to cope with it was to store the initial kohaversion and make a test. (see MT2308b on our git.)

Keep up the good job Chris.

But this is an old issue, and some points were made back in 2010 in a thread named How about a different way of handling database updates http://www.mail-archive.com/koha-devel@lists.koha.org/msg03423.html

Problem with patches and contributions more and more numerous will raise that again.

My 2 cents. -- Henri-Damien LAURENT _______________________________________________ Koha-devel mailing list Koha-devel@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/

-- Ian Walls Lead Development Specialist ByWater Solutions ALA Booth 732 Phone # (888) 900-8944 http://bywatersolutions.com ian.walls@bywatersolutions.com Twitter: @sekjal

On 25/05/11 13:55, Ian Walls wrote:

I think the problem with database revision numbers comes down to something fundamentally structural. Database revision numbers are linear, and are part of the Koha version number. But our development is non-linear; using Git, we work off Directed Acyclic Graphs.

From a development point of view it would be helpful if changes were reversible. It might be easier to do this if the changes were in a separate directory with an individual files for each change and a script that pulled the relevant ones in. It might make it easier to isolate if a stage failed rather than having them all embedded in a script. ( I'm thinking along the lines of Rails which I seem to recall handled database schema changes rather neatly).

There's no single solution out there but I think we could definitely do better if we put our minds to it Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 845 557 5634 (phone) +44 (0) 7759 633626 (mobile) colin.campbell@ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com