I think the key thing to keep in mind is that it isn't "Hibernate or Torque".. It's Hibernate/Torque/OJB and friends.. Half of the work in T2.3 was to make is easier to swap in various components. We shouldn't be tied down to implementation details like torque or hibernate, instead the turbine (or your app) should work via good clean interfaces and not care what the ORM tool is.
I'm expecting that people at some point are going to be asking why we can leverage commons-validator in our Intake code, a similar type situation. Admittedly, you have your own problems when you try and abstract totally away from your implementation. You can end up with a worst of all breeds solution. Something to look at is the xingu project. In it we have both OJB and Hibernate providers for some common objects like users, business objects, etc.. Proof that you can coexist with multiple providers. the Fulcrum security project that I worked on was another effort to faciliate multiple underlying persistence layers. For example, there are Memory persistence, Hibernate, and Torque. It would be simple to add in the OJB version as well. Note, the torque is pretty raw as I don't use it: http://jakarta.apache.org/turbine/fulcrum/multiproject/fulcrum-security/inde x.html Eric > -----Original Message----- > From: Martin Poeschl [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 10, 2003 7:47 AM > To: Turbine Users List > Subject: Re: Hibernate or Torque... What's the Future? > > > David Wynter wrote: > > >Hi Eric, > > > >In the second URL below you ask the question why have Group > in Security as > >it complicates things. Well my experience with this is that > it is useful. > >For example you can have users who have the role of > Accountant. One group > >might be the NW office and another Head Office. The 1st > group will have a > >restriction on accounts viewable based on the NW office cost > centre and the > >Head Office lot have no such restriction. You need the extra > dimension to > >manage this, unless you want to start muddying the > permissions with this. > >Groups in my experience are usually geographically distinct groups of > >people. > > > >By the way, the reason for my earlier problem with > TorqueComponent not > >running was that in the torque.properties distributed with torque 3.1 > >release as required by T2.3 release the use of > JDBC2PoolFactory in the > >commented out is no longer valid. I whad been using this > rather than the > >Torque Pool. I did not realise they had removed this between > torque 3.1 beta > >and release. Combined with the fragile exception handling in > T2.3 I took > >ages to find it. > > > > > read the changelog!! > the jdbc2 pool was just renamed as it was no good idea to > call it jdbc2 > .. now it's called SharedPool and the default properties file should > reflect this (i'll check this) > > what's about ojb?? > torque and ojb developers will join forces to make the torque > generator > work for ojb (it already has support for it) and i'll work on > migration > tools to make it easy to switch from torque to ojb ... as ojb is an > apache project (and i'm an ojb commiter ;-) i prefere to add > support for > ojb first > > martin > > >David > > > > > > > >>-----Original Message----- > >>From: Eric Pugh [mailto:[EMAIL PROTECTED] > >>Sent: 09 September 2002 16:52 > >>To: 'Turbine Users List' > >>Subject: RE: Hibernate or Torque... What's the Future? > >> > >> > >>I for one am hell for leather headed towards using Hibernate. I > >>used torque > >>before, but for various reasons decided to go for > Hibernate. You aren't > >>wasting your time building your project in torque however > IF, and big IF, > >>you use a good seperation between objects and data objects. > If you have > >>business logic spewed all over your various Torque objects, > then you will > >>hate life when it comes time to port. But, if you have data objects > >>(torque) and then either wrappers or business objects that > pull from data > >>objects, then porting is not too bad. > >> > >>What I learned was the ORM tools may come and go. Torque, > then Hibernate, > >>but I bet is in time it'll be something else. Hence the reason > >>to seperate > >>it out. > >> > >>Basically, if you can write your app with NO persistence, and > >>then later add > >>your persistence in, then you wrote it correctly, and plugging in > >>Torque/Hibernate/JDO will be okay... > >> > >>I use hibernate extensively and successfully with Turbine. > There is a > >>howto: > >>http://jakarta.apache.org/turbine/turbine-2.3/howto/hibernat > e-howto.html > >>available. Getting started with Hibernate via Avalon also > get's you ready > >>for T2.4 and lots of Avalonized components! > >> > >>Also, > >>http://jakarta.apache.org/turbine/fulcrum/multiproject/fulcrum-sec > >>urity/inde > >>x.html there is a hibernate based security system. And in the > >>unit tests is > >>an example of using it in t2.3 with the turbine > user/groups/roles etc... > >> > >>Eric > >> > >> > >> > >>>-----Original Message----- > >>>From: Matthew Pomar [mailto:[EMAIL PROTECTED] > >>>Sent: Tuesday, September 09, 2003 5:09 PM > >>>To: [EMAIL PROTECTED] > >>>Subject: Hibernate or Torque... What's the Future? > >>> > >>> > >>>A proposal is included in Turbine version 2.3 to integrate > Hibernate. > >>> > >>>It is my impression Hibernate is widely used and has fantastic > >>>documentation. There are a number of code generation > >>>utilities for it, and > >>>it appears to be well tested and high performance. > >>> > >>>I would like to make sure that I'm not wasting my time > >>>builing my project on > >>>Torque if it will be replaced by Hibernate in the near future. > >>> > >>>Does anyone know the status of the Hibernate integration? > >>> > >>>Thanks, > >>> - Matt > >>> > >>> > > > > --------------------------------------------------------------------- > 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]
