Hi Allen, On Aug 15, 2006, at 2:03 PM, Allen Gilliland wrote:
Craig,before we talk about the Datamapper specifically I think it would help to settle a couple more general things about what we are planning to do for the new persistence implementation ...primarily, I think we need to figure out what we are going to implement. so far you have talked about JDO and JPA, and we already have Hibernate, so those are the options on the table right now. as far as I'm concerned we should be picking one of them and focus there because I am still not interested in planning multiple backend implementations.
I understand. What I found while looking at adapting the Hibernate implementation is that most of the code is not really Hibernate- specific. It's "datamapper" specific, and any implementation of the datamapper architecture is going to look the same, modulo calling Hibernate's session api versus calling JDO's persistence manager versus JPA's entity manager.
So the alternative for me is copy/paste 1000 lines of Hibernate code and change session.saveOrUpdate to persistencemanager.makePersistent or entitymanager.persist. Since I think it's inevitable that once there's a JDO implementation, someone is going to want a JPA implementation, I decided not to copy/paste directly to a specific API but simply make one level of abstraction. So when I see session.saveOrUpdate, I replace it with strategy.store.
that's not really useful to people who are running roller and it's more overhead to maintain for us roller developers.
Well, the maintenance of the XXXManager remains. There is very little extra code to maintain: just the mapping between strategy and the specific implementation.
assuming we agree that we are only focusing on implementing one of the options, we then need to decide which one. just so it's known, i think it's entirely lame that we are getting rid of Hibernate over a silly licensing issue.
Yeah, I'm not going to get into why we're not comfortable enough with Hibernate because that's not the open issue at the moment.
as a large roller customer i consider it more of a pain than a benefit to have to replace the backend. regardless of that fact, it appears that's what everyone wants to do, so i consider Hibernate to no longer be an option. that leaves JDO and JPA as you mentioned, and i don't really have any preference between the two.
If you want to reduce the maintenance burden, given that there will be another back end, I guess a strategy is to write a Hibernate implementation of datamapper as well. And you probably know that there is some additional metadata to add to the persistent classes via doclet or annotations or xml. Hopefully the data model is not changing so rapidly that this is a big burden.
Personally, I have no axe to grind on Hibernate v. JDO v. JPA. Craig
-- Allen Craig L Russell wrote:Hi,Here's what I propose as a starting point for the query interface between Datamapper Managers and Datamapper Persistence. There are enough differences between JDO, JPA, and Hibernate that I found it really awkward to define a set of methods on PersistenceStrategy that covered the functionality. In particular, there are two methods in JPA that both execute the query and determine the result shape, and parameters are passed one by one. In JDO, there is an API that determines the result shape and one method to execute the query, passing parameter values. It's trivial to encapsulate these differences in a Query instance. I've included the Query API below for discussion, along with calling sequence from Mapper.Craig public class DatamapperPersistenceStrategy { ... /** * Create query. * @param clazz the class of instances to find * @param queryName the name of the query * @throws org.apache.roller.RollerException on any error */ public DatamapperQuery newQuery(Class clazz, String queryName) throws RollerException; } public class DatamapperUserManagerImpl { ...public WebsiteData getWebsiteByHandle(String handle, Boolean enabled)throws RollerException { // XXX cache websites by handle? return (WebsiteData)strategy.newQuery(WebsiteData.class, "getByHandle&&Enabled") .execute(new Object[]{handle, enabled}); } public interface DatamapperQuery { /** Execute the query with no parameters. * @return the results of the query */ Object execute(); /** Execute the query with one parameter. * @param param the parameter * @return the results of the query */ Object execute(Object param); /** Execute the query with parameters. * @param params the parameters * @return the results of the query */ Object execute(Object[] params); /** Remove instances selected by the query with no parameters. * @return the results of the query */ void removeAll(); /** Remove instances selected by the query with one parameter. * @param param the parameter * @return the results of the query */ void removeAll(Object param); /** Remove instances selected by the query with parameters. * @param params the parameters * @return the results of the query */ void removeAll(Object[] params); /** Set the result to be a single instance (not a List). * @result the instance on which this method is called */ DatamapperQuery setUnique(); /** Set the types of the parameters. This is only needed if the * parameter types are temporal types, e.g. Date, Time, Calendar. * @param the types of the parameters in corresponding positions. * @result the instance on which this method is called */ DatamapperQuery setTypes(Object[] types); /** Set the range of results for this query. * @fromIncl the beginning row number * @toExcl the ending row number * @return the instance on which this method is called */ DatamapperQuery setRange(long fromIncl, long toExcl); } Craig Russell [EMAIL PROTECTED] http://db.apache.org/jdo
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
