We were discussing the following at hackfest:

a directory of atomic database updates.  While my intent was for .pl files, we could adapt to include .sql, as well.  I just really like the idea of a CHECK/DO/UNDO interface

A YAML file, edited by the RM only, that assigns those update files to a specific database revision number.  This gives us a quick and ordered means of determining what has been "blessed" by the release team, and allow us to continue a quick check of "is DB version equal to software version?" on every page.

If a user needs to make a local change, they can either apply the atomic update file directly (for testing), or add it to the YAML file, but with a placeholder string like "LOCALNUMBER" instead of an actual DB rev number.  This would allow people to put together their own database update combinations for local developments, without getting their DB version number out of whack.

The script that reads the YAML file and applies the update can be called just in the event that DB number != Code number.  This would require that the sysadmin manually add the atomic update the first time, but if they're applying patches that require DB updates, they should be savvy enough to complete that small additional step.

I do like the idea of hashes... but looking at it, we'd essentially be mimicking the data structure we already have with Git commits.  Plus, readability goes down.

Cheers,


-Ian

On Thu, Nov 24, 2011 at 5:37 AM, MJ Ray <mjr@phonecoop.coop> wrote:
Robin Sheat <robin@catalyst.net.nz>
> Perhaps a quick hash/CRC of the filenames of the patches that have been
> applied? Should be quick to generated and test, and will tell us
> immediately if we need to run again.

That was another idea, but I thought a sufficient hash would be a very
long version number from the start and also would not necessarily
increase as updates are applied, or tell us simply which updates have
been applied when people ask for help, so I went with multiplying
primes.

But both have their merits.  Hash, CRC or primes are fine by me.

Regards,
--
MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op.
Webmaster, Debian Developer, Past Koha RM, statistician, former lecturer.
In My Opinion Only: see http://mjr.towers.org.uk/email.html
Available for hire for various work through http://www.software.coop/
_______________________________________________
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
Phone # (888) 900-8944
http://bywatersolutions.com
ian.walls@bywatersolutions.com
Twitter: @sekjal