On Fri, 2004-12-03 at 17:02 +0100, Oliver Zeigermann wrote: > Has anyone got any idea what role Spring would play in all this???
Headache? ;) I think migration to an IoC framework is definitely something that should wait until 3.0. Also, it would mean something else that new developers would have to learn. Not necessarily bad, but something to to consider. Other than that it seems like a nice idea, and may make the code a bit cleaner. -James > > Oliver > > > On Fri, 3 Dec 2004 16:57:42 +0100, Oliver Zeigermann > <[EMAIL PROTECTED]> wrote: > > Some sort of very short pratcial OJB introduction at : > > > > http://blogs.codepuccino.com/dude/index.php?p=23 > > > > Oliver > > > > > > > > On Fri, 3 Dec 2004 16:24:35 +0100, Oliver Zeigermann > > <[EMAIL PROTECTED]> wrote: > > > 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]
