Hi (again :D), the filtering script idea is just to be able to adapt to existing tables & data. I'm not 100% sure right now, but I think that the HSQL & PostgreSQL scripts are db specific (could be wrong). Also, they can be used for production, although in the build they're used for testing. To enable specific Postgre testing, a manual download of the driver and tweaking the build script slightly was needed, if I recall correctly.
br, juan pablo On Fri, May 17, 2013 at 3:26 AM, Glen Mazza <glen.ma...@gmail.com> wrote: > Hi Team, > > Unsure, but I'm inclined to simplify our database creation scripts, > presently we use a bunch of symbolic terms instead of the actual table and > column names: > http://svn.apache.org/viewvc/**incubator/jspwiki/trunk/etc/** > db/hsql/userdb-setup.ddl?**revision=1426919&view=markup<http://svn.apache.org/viewvc/incubator/jspwiki/trunk/etc/db/hsql/userdb-setup.ddl?revision=1426919&view=markup> > > The real table and column names are replaced/filtered from the > jspwiki.properties file here: > http://svn.apache.org/viewvc/**incubator/jspwiki/trunk/src/** > test/resources/jspwiki.**properties?revision=1479697&**view=markup#l99<http://svn.apache.org/viewvc/incubator/jspwiki/trunk/src/test/resources/jspwiki.properties?revision=1479697&view=markup#l99> > > The idea is that we can change a table or column name in one place > (jspwiki.properties) and it will cascade to the hsql and postgresql > scripts. However, we only have a few tables and we almost never (probably > never) change table and column names anyway. I think it might be good to > remove the filtering and just hardcode the table and column names in the > create scripts. That will simplify the Maven pom and jspwiki.properties > files a bit as well as make the system easier to understand. WDYT? > > Also, do we need the PostgreSQL scripts today? > http://svn.apache.org/viewvc/**incubator/jspwiki/trunk/etc/**db/<http://svn.apache.org/viewvc/incubator/jspwiki/trunk/etc/db/>First > of all I'm unsure if these database scripts (hsql and postgresql) are > for production also or only test, if the latter, we only test with hsql > anyway so maybe we can delete PostgreSQL. If this is also for production, > I would guess 90% are happy with hsql and those not happy with hsql aren't > going to be any happier with PostgreSQL (i.e., people leaving hsql would > rather switch to MySQL, Derby, Oracle, etc...) Then again, maybe we > provide two database options to make sure we're not coding in a specific > database-dependent manner. > > Regards, > Glen > >
