Are you talking about a product like ofbiz that abstracts away the db
implementation and creates an object (entity) layer instead? It would be
great but would require quite a lot of work. We use ofbiz for another of our
products and all of the tables and table joins (views) would need to be
modelled as objects and then mapping classes written to set/get the data
into these objects. And then another layer on top of that to map an object
to the appropriate mapping class and provide a service interface to the
object repository. It's a great idea, though, and with a mature product like
ofbiz it would be great.

Warwick


> -----Original Message-----
> From: Carlos Villegas [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, December 02, 2004 6:18 PM
> To: Slide Users Mailing List
> Subject: Re: developers: table prefix
> 
> 
> This is simple enough. But how about using one of the O/R 
> mapping tools 
> like Hibernate, Apache's OJB or Torque. The table names or 
> mappings are 
> usually setup in an external configuraton file. It adds additional 
> benefits like supporting more databases and keeping all the database 
> adapters in sync since they all become just one. Converting 
> JDBC code to 
> OJB, for example, is straightforward, we have done it, specially if 
> there are no stored procedures like in Slide.
> 
> Carlos
> 
> Warwick Burrows wrote:
> > There's something about preprocessing Java source that makes me a 
> > little uneasy :-) Isn't there another way? eg. instead of 
> inserting a 
> > placeholder that gets replaced simply change the jdbc operation 
> > strings passed to the jdbc client as in this example?
> > 
> >     "select name from " + Config.table_prefix + "PROPERTIES where 
> > field=1"
> > 
> > Java will insert the prefix into the command automatically. 
> There's no 
> > need for preprocessing and the amount of work required to 
> change the 
> > code to suit this approach is no more or less than that needed to 
> > insert a placeholder string?
> > 
> > Warwick
> > 
> > 
> > 
> >>-----Original Message-----
> >>From: Richard Emberson [mailto:[EMAIL PROTECTED]
> >>Sent: Thursday, December 02, 2004 3:51 PM
> >>To: Slide Users Mailing List
> >>Subject: developers: table prefix
> >>
> >>
> >>
> >>This subject has been kicked around recently. Basically,
> >>there is an easy way to do it but if none of the Slide 
> >>developers are interested then it will never go anywhere.
> >>
> >>How to add table prefixes to Slide's database table names -
> >>the simple way:
> >>
> >>Alter the build.xml file so that it does a filtered copy to a
> >>new directory "build/gen_src" prior to compilation.
> >>  It is from this directory that the
> >>sources are then compiled. Each table name in the source has 
> >>the string "@TABLE_PREFIX@" prepened to it. The 
> >>build.properties file has a new property:
> >>
> >>table.prefix=<value>
> >>
> >>The "value" can be, for example, empty resulting in the
> >>current table names or one might set the value to "SLIDE_" 
> >>which would result in that string being prepended to all 
> table names.
> >>
> >>Additional benefits:
> >>
> >>One can now add properties to the build.properties file:
> >>
> >>version.major=2
> >>version.minor=1
> >>version.release=0
> >>
> >>which could be used during the filtered copy to embed the Slide 
> >>version number is some class which can be accessed at runtime.
> >>
> >>The build date, who built the code, compile host
> >>architecture, java version and vender doing compilation, cvs 
> >>version tag, etc. can also be generated by ant and used 
> >>during the filtered copy to add more runtime accessible 
> >>information. For those embedding Slide in a J2EE application, 
> >>this information would then be accessible via a JMX page.
> >>
> >>None of this is hard to do, its just a question of
> >>identifying someone (with checkin ability) to take the first 
> >>step - altering the build process.
> >>
> >>Richard
> >>
> >>
> >>
> >>--
> >>This email message is for the sole use of the intended 
> >>recipient(s) and may contain confidential information.  Any 
> >>unauthorized review, use, disclosure or distribution is 
> >>prohibited.  If you are not the intended recipient, please 
> >>contact the sender by reply email and destroy all copies of 
> >>the original message.
> >>
> >>------------------------------------------------------------
> ---------
> >>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> > 
> > 
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > 
> > 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to