Menu
▾
▴
springframework-developer
|
From: Juergen H. <ju...@in...> - 2005-05-28 11:05:18
|
Hi Marc, I wouldn't be opposed to add in-memory queries explictly, although there's of course always the option to implement a whole sequence of JDO operations in a JdoCallback, operating on the passed-in PersistenceManager. I can't tell how common the use of in-memory queries is... You hit a nail there :-) The JDO section in the reference docs is overdue. A TopLink section needs to be added as well. We simply haven't found the time to address those yet. You are of course very welcome to contribute! I guess we should officially start the JDO doc ASAP, with release 1.2.2 as target for a first version. Colin/Rob, what are your thoughts on this? Could we maybe start with collecting some stuff from the wiki? Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Marc Logemann Sent: Saturday, May 28, 2005 11:50 AM To: spr...@li... Subject: [Springframework-user] JDOTemplate and in-memory queries Hi, would it make sense to add in-memory queries to JDOTemplate. So instead of doing: Collection col = // some results of former DB operation Query q2 = pm.newQuery(My.class, col, "attr == searchstr"); Collection col2 = (Collection) q2.execute(); This could be done by enhancing JDOTemplate: col = template.findInCollection(My.class, "attr == searchstr", col) The only problem i see is that you need a lot of variants of findInCollection() as seen in find(). Comments? BTW is there any reason that the JDO section is still blank in the Spring docs? Or am i the only one using JDO with Spring ;-) I would join efforts if something is underway. -- regards Marc Logemann http://www.logemann.org http://www.logentis.de ------------------------------------------------------- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 _______________________________________________ Springframework-user mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-user |
|
From: Marc L. <ma...@lo...> - 2005-05-28 12:58:28
|
Juergen Hoeller wrote: > I wouldn't be opposed to add in-memory queries explictly, although there's > of course always the option to implement a whole sequence of JDO operations > in a JdoCallback, operating on the passed-in PersistenceManager. I can't > tell how common the use of in-memory queries is... If you use JDO heavily like i do, then you will definitely use this feature. I could make a proposol for the enhancement of JDOTEmplate. Should i place this in JIRA for further reviewing? > You hit a nail there :-) The JDO section in the reference docs is overdue. A > TopLink section needs to be added as well. We simply haven't found the time > to address those yet. You are of course very welcome to contribute! I ve written something for the wiki allready and i ve made my experiences with JDO and Spring, even though i am far away from being perfect, so yes, i can contribute if one or two people can jump in too. > I guess we should officially start the JDO doc ASAP, with release 1.2.2 as > target for a first version. Colin/Rob, what are your thoughts on this? Could > we maybe start with collecting some stuff from the wiki? We could use the same structure as with the hibernate spring docs cant we, because the approaches of them are pretty much the same. How can a collabiration look like? I dont want to write things others have allready written. -- regards Marc Logemann http://www.logemann.org http://www.logentis.de |
|
From: Juergen H. <ju...@in...> - 2005-05-28 13:40:00
|
Yes, if you have a create proposal on your mind, then please create a JIRA issue for it. The JDO doc section can certainly be based on our Hibernate docs. Moving forward, I guess Colin and myself are gonna care for it overall, with community contributions (up to entire sections) getting merged in. FYI, I'm about to leave for Denmark, returning on Wednesday - which means I'm not available for kicking this off till mix next week. Feel free to create JIRA issues and/or gather stuff on the wiki in the meantime :-) Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Marc Logemann Sent: Saturday, May 28, 2005 3:00 PM To: spr...@li... Subject: [Springframework-developer] Re: [Springframework-user] JDOTemplate and in-memory queries Juergen Hoeller wrote: > I wouldn't be opposed to add in-memory queries explictly, although there's > of course always the option to implement a whole sequence of JDO operations > in a JdoCallback, operating on the passed-in PersistenceManager. I can't > tell how common the use of in-memory queries is... If you use JDO heavily like i do, then you will definitely use this feature. I could make a proposol for the enhancement of JDOTEmplate. Should i place this in JIRA for further reviewing? > You hit a nail there :-) The JDO section in the reference docs is overdue. A > TopLink section needs to be added as well. We simply haven't found the time > to address those yet. You are of course very welcome to contribute! I ve written something for the wiki allready and i ve made my experiences with JDO and Spring, even though i am far away from being perfect, so yes, i can contribute if one or two people can jump in too. > I guess we should officially start the JDO doc ASAP, with release 1.2.2 as > target for a first version. Colin/Rob, what are your thoughts on this? Could > we maybe start with collecting some stuff from the wiki? We could use the same structure as with the hibernate spring docs cant we, because the approaches of them are pretty much the same. How can a collabiration look like? I dont want to write things others have allready written. -- regards Marc Logemann http://www.logemann.org http://www.logentis.de ------------------------------------------------------- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Marc L. <ma...@lo...> - 2005-05-28 13:54:44
|
Juergen Hoeller wrote: > FYI, I'm about to leave for Denmark, returning on Wednesday - which means > I'm not available for kicking this off till mix next week. Feel free to > create JIRA issues and/or gather stuff on the wiki in the meantime :-) Colin, perhaps we can discuss that, because i want to start with the first section called "Resource Definitions in an Application Context" But we should agree on one approach in doing this. In my application i am doing it the same way as you ve done it for the wiki with Kodo. Is it possible to generalize this KodoPersistenceManagerFactoryBean (just different naming?) and place it in the Spring tree, this way we would have the same approach as with Hibernate. We would have a seperate Datasource definition and the linking to the JDO resource via "connectionFactory". I could also start with some general blabla in a section called "Resource Management". Also the same as with Hibernate spring docs. Perhaps other might want to continue with sections like: - Inversion of Control: Template and Callback - Transactions Just a proposal. Happy to hear more on this from Rob or Colin. Hope its ok to just proceed with the documentation issue. I dont want too many users switching to hibernate just because Spring has no JDO docs <g>. -- regards Marc Logemann [blog] http://www.logemann.org [busn.] http://www.logentis.de |
|
From: Colin S. <col...@ex...> - 2005-06-09 21:37:25
|
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. I agree also about the need for JDO docs. I may be able to help some here in the shorter term, although my first priority for docs is the Annotations stuff, and I need to spend most of my free Spring dev time on trying to help with the build/source organization refactoring we've been talking about for a while now and are probably going to go ahead with. At a minimum I should be able to proof and comment on anything you put out. Colin Marc Logemann wrote: > Juergen Hoeller wrote: > >> FYI, I'm about to leave for Denmark, returning on Wednesday - which >> means >> I'm not available for kicking this off till mix next week. Feel free to >> create JIRA issues and/or gather stuff on the wiki in the meantime :-) > > > Colin, perhaps we can discuss that, because i want to start with the > first section called "Resource Definitions in an Application Context" > > But we should agree on one approach in doing this. In my application i > am doing it the same way as you ve done it for the wiki with Kodo. Is > it possible to generalize this KodoPersistenceManagerFactoryBean (just > different naming?) and place it in the Spring tree, this way we would > have the same approach as with Hibernate. We would have a seperate > Datasource definition and the linking to the JDO resource via > "connectionFactory". > > I could also start with some general blabla in a section called > "Resource Management". Also the same as with Hibernate spring docs. > > Perhaps other might want to continue with sections like: > > - Inversion of Control: Template and Callback > - Transactions > > Just a proposal. Happy to hear more on this from Rob or Colin. Hope > its ok to just proceed with the documentation issue. I dont want too > many users switching to hibernate just because Spring has no JDO docs > <g>. > |
|
From: Marc L. <ma...@lo...> - 2005-06-09 22:06:31
|
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 |
|
From: Juergen H. <ju...@in...> - 2005-06-12 15:52:48
|
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 |
