I've been assuming all this time, without stating the assumption, that new database changes would only be appended to the list in updatedatabase.pl. I thought that would guarantee the linearity that you are talking about. Of course it is important to have this linearity fro the reasons you have mentioned. Maybe my assumption is unreasonable since it doesn't enforce linearity.
With Galen's requests to take into account to this become a very difficult problem to solve. We need a system that enforces itself, but is flexible. Gonna have to think about that alot. I think the key is is Galen's fifth point: being able to easily renumber updates before submission to HEAD. On Wed, 2010-02-03 at 11:43 -0500, Joe Atzberger wrote: > It doesn't matter whether it is a string or not. Once you remove the > linearity of the update process, you no longer know what revision X > means. You could have got there by applying X to: > * 3.00.04.019, > * 3.02.01.555, > * "Z", or even > * "2.00.00.01". > It means you have applied patch X, it does not mean database state X. > The linearity of the process is why we happen to use numbers to > describe it, since numbers have an agreed-upon order. That's why your > approach would need a log of every update applied AND the order of > application instead of just the version label. Because if one > revision "A" creates a table and another "B" drops it if it exists, > you get totally different results if you run them AB vs. BA. > > > Currently 3.00.04.019 implies 3.00.04.018, 3.00.04.017, etc. The > proposed scheme forces us to know the entire contents of the upgrade > log to know the database state. That is to say, you need to READ the > database, to know what the database should look like. This violates > some distinctions we would otherwise like to retain between structure > and data. > --Joe -- Michael Hafen Systems Analyst and Programmer Washington County School District Utah, USA for Koha checkout http://development.washk12.org/gitweb/ or git://development.washk12.org/koha _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
