Since right now we check that the DB is up to date with every page load, we'd need something fast. A numeric comparison is simple enough; checking through a whole directory of updates, or scanning a hashref or some other mechanism, would likely take much more processing power.
Also, we've got to factor in update's depending on one another. We've got to have some kind of chain of dependence; doing it as a linear value is the easiest. The other option would be for each update to specify it's dependencies explicitly; that would give us a directed acyclic graph, like Git uses, but would be MUCH more complex to implement and maintain.
-Ian
> During the hackfest in Mumbaï, 5 of us had a brainstorming about
> database changes to try to improve it.
Would it be feasible for the database not to track a linear version number of the update status, but a list of tickets, one for every DB update?
Given these tickets are unique (centrally managed or random, i.e., a hash of the DB statements) you would have no troubles whatsoever applying patches in any order. You would even (with a corresponding un-apply DB statements file) be able to roll back individual patches.
Of course, this means the update has to walk through the ticket numbers instead of checking a single version number. In case that's too expensive for the general case of a non-patched system, the update script could be taught a list of tickets of the updates that each released version contains. But I guess looking up a ticket number in a list maintained by the DB is exactly what a DB is good at.
_______________________________________________
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/