Does anyone else have comments on the ofbiz entity engine?
(http:/www.ofbiz.org). We've been using it in our product and have found it
works great and is fast and mature. The entity engine is just one component
of a larger product suite. It has an MIT open source license. And one of the
ways the website serves up their source via a WebDAV server ;-)
http://svn.ofbiz.org/svn/ofbiz

Warwick


> -----Original Message-----
> From: Nick Longinow [mailto:[EMAIL PROTECTED] 
> Sent: Friday, December 03, 2004 9:33 AM
> To: 'Slide Users Mailing List'; [EMAIL PROTECTED]
> Subject: RE: developers: table prefix
> 
> 
> I'm in agreement with you on keeping maintenance and complexity to a
> (reasonable) minimum.  
> Nick
> 
> -----Original Message-----
> From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] 
> Sent: Friday, December 03, 2004 10:25 AM
> To: Slide Users Mailing List
> Subject: Re: developers: table prefix
> 
> I would definitely be +1 for moving to a ORM tool. There is 
> *soo* much maintenance with all these different dbs. As 
> Hibernate is no option *right now*, and I have zero 
> experience with OJB I had a lookt at ibatis. It's nice, but 
> it is an SQL mapper only and can not help us with different dbs :(
> 
> Would be great if you could do a start with OJB. Maybe others 
> will chime in as soon as the initial pain of getting it 
> started is over.
> 
> Oliver
> 
> On Fri, 03 Dec 2004 11:15:28 +0900, Carlos Villegas 
> <[EMAIL PROTECTED]> wrote:
> > Well I have experience with OJB but not the time :-(
> > I had promissed to look at the issues about the 
> property-value field 
> > for storing lists like the revisions or group members. 
> Maybe I can do 
> > it as part of that but I'm still trying to make the time... 
> OJB will 
> > do just fine for Slide purposes and it's simple enough. The 
> Java code 
> > for OJB is very readable, more than the embedded SQL in raw 
> JDBC which 
> > adds to the maintainability.
> > 
> > Carlos
> > 
> > 
> > 
> > James Mason wrote:
> > > This is sort of on my todo list, but the only O/R tool 
> I'm familiar 
> > > with is Hibernate and for licensing reasons we can't 
> integrate that 
> > > with Slide (this may change in the future). I looked at 
> OJB, but I 
> > > wasn't impressed with some of the hoops I would have to 
> jump through 
> > > to accomplish, for example, lazy instantiation.
> > >
> > > I think this is the right way to go, if someone with the time and 
> > > knowledge is willing to chip in. Right now I don't really have 
> > > either :).
> > >
> > > -James
> > >
> > > On Fri, 2004-12-03 at 09:18 +0900, Carlos Villegas wrote:
> > >
> > >>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
> > 
> > 
> ---------------------------------------------------------------------
> > 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