Re: [Springframework-developer] JDOTemplate and in-memory queries

[Juergen H. <ju...@in...>]

FYI, I've spent my train time to Ulm and back (8 hours in total) on our O/R
Mapping docs: I've added pretty complete sections on JDO, TopLink and OJB.
Of course, there's always room for improvement, but I believe that the
present sections are a good start.

The JDO section currently talks about two PersistenceManagerFactory setup
styles: LocalPersistenceManagerFactoryBean and direct instantiation of a PMF
impl class (analogous to a DataSource). The section contains an example for
both, with the latter showing JPOX setup.

I've also refined the Hibernate and iBATIS sections a bit. The only
important thing that's still missing is a discussion of OpenSessionInView /
OpenPersistenceManagerInView.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Marc Logemann
Sent: Friday, June 10, 2005 12:09 AM
To: spr...@li...
Subject: Re: [Springframework-developer] JDOTemplate and in-memory
queries


Hi,

i must have been blind not to see the kodo libs in the wiki code
(KodoPersistenceManagerFactoryBean) and yes, of course this is a show
stopper for the docs and the distro. In the last minutes i thought about
a solution to this. Of course we could just start writing the docs with
the explanation of setting up JDO with plain LocalPersistenceManagerFB
but i dont like the approach to define the driver stuff inside
jdoProperties. I really think a seperate datasource definition and the
linking via dataSource property would be the best way. Here one can
reuse that datasource for Quartz or other persistence mechanisms.

Unfortunately, this cant be done in a vendor neutral way as it seems.
Perhaps i should look into JDO2 spec again, it think they also improved
and unified the bootstrapping stuff with JDO2. Correct me if i am wrong
with my assumption.

I have the same problem as colin right now that my time is very limited
due to project issues but i can take a look at the JDO2 spec in order to
see if we can somehow transport the beautiness of the KodoPMFB to a
common JDO(2) class. If this is not possible, we have to go with
LocalPersistenceManagerFactoryBean and document that.



Colin Sampaleanu wrote:
> Marc,
>
> Sorry for the _extreme_ delay in this reply. I was busy at the time you
> initially posted, put it aside for a day or two to have time to think
> about it properly and reply, and then got even busier.
>
> The main reason the Kodo stuff is not in CVS right now is that to build
> it it does require linking to the Kodo lib, and the latter is not free.
> I don't see much of a solution for this unless Solarmetric perhaps does
> something like allow us to put a non-working Kodo lib in CVS against
> which we can build, but which we don't distribute. alternately they
> could maintain it themselves, and we could link to it. However, that's
> actually a tiny class, so I don't necessarilly even see that big a deal
> with just listing the class in docs, and pointing to somewhere where
> it's avaialble for download too.


--
regards
Marc Logemann
[blog] http://www.logemann.org
[busn.] http://www.logentis.de


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you
shotput
a projector? How fast can you ride your desk chair down the office luge
track?
If you want to score the big prize, get to know the little guy.
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer