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]
