Hi Dave, On May 26, 2006, at 2:41 PM, Dave Johnson wrote:
The only parts of the Hibernate implementation that are Hibernate- specific have to do with the criteria queries, which will require a criteria API in the JDO/Hibernate/EJB3 implementation.You know, I wrote a complete criteria query API back in the 0.9.9 code base and an implementation for Castor-JDO (which generated OQL) and Hibernate (which generated HSQL). We had it in production at JRoller.com for a while, but we dropped it when we completely dropped Castor-JDO support (code is here -> http://tinyurl.com/k7lgm).Cool idea, but I must admit that I'm a little concerned about maintaining a criteria API infrastructure in Roller. Seems like a criteria API should be part of JDO and/or JPA instead.Are you proposing to implement the Hibernate Criteria API verbatim or something new?
It looks like the Hibernate criteria API is only minimally used, and a different approach will probably be better. The only Hibernate criteria APIs that are actually in use are .eq, .gt, .addOrder, .isNull, .isNotNull, .setMaxResults, which can easily be put into static queries.
Oh, yes, there is one really big query in ReferrerManagerapplyRefererFilters(WebsiteData website) for blacklists. We will definitely have to use a dynamic query for that one.
One possibility is to just use static queries which are supported by both JPA and JDO. The queries can be stored in metadata for easy updating (instead of editing the .java files). I'll take a closer look at the queries to make a definite proposal here.
This way, the only code specific to EJB3 or JDO would be the implementation of DatamapperPersistenceManager and Roller interfaces.So, the JDO specific parts of the implementation would be confined to two classes? That sounds too good to be true.Of course it's too good to be true. But that's the objective.OK, I understand now. It might be good to come up with a brief proposal on the wiki that outlines the design. I'd be glad to help with that.
If you point me to the wiki page, I'll be happy to work there.
And, instead of working in the sandbox, how about we make a new branch for this work. That might be easier for us all.
Sure. I'm happy to keep working in my private workspace sandbox until I get something that actually compiles. Feel free to create whatever infrastructure you think makes sense for the project. It can probably wait until we have consensus on the wiki...
Craig Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
