The testing framework uses h2 to supply an ephemeral in-memory database, rather than having to create and clean up a Pg or Oracle database. Because every convenience must have a price, h2 accepts DDL that is not quite like either Pg or Oracle and thus requires its own version of the schema. Right now this version is tucked away in dspace-api/src/test/resources where one might never think to look. Would there be objection to moving it into dspace/etc/h2 right alongside dspace/etc/postgresql and dspace/etc/oracle where there is a fighting chance that someone updating the other schemata would attempt corresponding changes to the h2 schema? We might filter it out during final assembly, so people don't get the idea that they can use h2 in a production DSpace and complain if the result doesn't work quite right.
(Even better would be finding a gadget to mechanically transform Pg or Oracle DDL into h2 DDL, or to generate all three from a common precursor, but I couldn't be that lucky.) -- Mark H. Wood, Lead System Programmer [email protected] Asking whether markets are efficient is like asking whether people are smart.
pgpQbFBWLVG7U.pgp
Description: PGP signature
------------------------------------------------------------------------------ EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
_______________________________________________ Dspace-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-devel
