Some context:

I created the Postgres scripts mostly because that was the database I used in 
production, not so much because of a surge in requests for Postgres support. :)

The filtering scripts were made so that, in theory, one could easily map into 
an existing database where user and group info was kept.

In practice I think our implementation of password hashing, for example, makes 
it unlikely that JSPWiki would ever share a database with another application. 
It's too specific to JSPWiki.

So, +1 on both of Glen's recommendations. I agree with his logic.

Andrew

On May 17, 2013, at 10:22 PM, Glen Mazza <[email protected]> wrote:

> 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 <[email protected]> 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
>>> 
>>> 
> 

Reply via email to