Are you sure? The filtering is used only with "CREATE TABLE" and
subsequent INSERT INTO statements, so there's no adapting to existing
tables that could be occurring. All I can see with the filtering, is, as
I mentioned earlier, if we decide to change a table or column name in
jspwiki.properties so it propagates to both the PostgreSQL and the
HSQLDB scripts, a use case that in addition to never happening doesn't
help much as it would be easy to update two files anyway. i.e., the
added complexity seems to be well failing cost/benefit analysis.
Further, an external user won't be able to use the scripts as-is without
running Ant to populate the table and column names, so it's not helping
external users--they would benefit from no filtering because it can give
them scripts they can use OOTB without messing with Maven/Ant.
All we ever test on personally in hsqldb today, which indicates we
(ourselves) don't need the postgresql scripts (I'm guessing JSPWiki
first used PostgreSQL while HSQLDB was a newcomer, but now the latter is
much more common than the former--the scripts themselves date to 2006
judging from the timestamps in the insert statements); further, for
external users, these are very simple create table statements, easily
adaptable as anyone would like to Oracle/MySQL/Derby/SQLServer whatever,
they won't be benefitting from a second set of PostgreSQL SQL
statements. I mean if we had HSQL and MySQL, or Derby or Oracle scripts
that might make sense to retain, but not that many care about PostgreSQL
today.
While I can activate filtering in Maven as well, that's doable (we're
doing enough of it already), without any further information to the
contrary I'd +1 on getting rid of the filtering and the postgresql
scripts, let's simplify here and we can easily bring it back later
should we get requests for it.
Glen
On 05/17/2013 07:22 PM, Juan Pablo Santos RodrÃguez wrote:
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
