You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@roller.apache.org by Craig L Russell <Cr...@Sun.COM> on 2006/08/15 20:21:27 UTC
Query interface for Datamapper
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
clr@apache.org http://db.apache.org/jdo
Re: Query interface for Datamapper
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Allen,
I excerpted parts of the code I uploaded to the JIRA issue so we
could discuss some salient parts. The full upload is at http://
opensource.atlassian.com/projects/roller/browse/ROL-977
I thought that the 82K would make for an awkward email discussion if
I included the whole thing.
On Aug 16, 2006, at 7:38 PM, Allen Gilliland wrote:
> comments inline ...
>
> Craig L Russell wrote:
>> Hi,
>> Here's what I propose as a starting point for the query interface
>> between Datamapper Managers and Datamapper Persistence.
>
> This already confuses me. Exactly how much stuff are we adding?
Here's most of it:
svn status sandbox/jdobackend/
? sandbox/jdobackend/lib/jdom.jar
? sandbox/jdobackend/lib/jdo2-api-2.0.jar
A sandbox/jdobackend/src/org/apache/roller/business/jdo/
JDOPersistenceStrategy.java
A sandbox/jdobackend/src/org/apache/roller/business/jdo/
JDOQueryImpl.java
A sandbox/jdobackend/src/org/apache/roller/business/datamapper
A sandbox/jdobackend/src/org/apache/roller/business/datamapper/
DatamapperPlanetManagerImpl.java
A sandbox/jdobackend/src/org/apache/roller/business/datamapper/
DatamapperPingTargetManagerImpl.java
A sandbox/jdobackend/src/org/apache/roller/business/datamapper/
DatamapperRollerImpl.java
A sandbox/jdobackend/src/org/apache/roller/business/datamapper/
DatamapperBookmarkManagerImpl.java
A sandbox/jdobackend/src/org/apache/roller/business/datamapper/
DatamapperAutoPingManagerImpl.java
A sandbox/jdobackend/src/org/apache/roller/business/datamapper/
DatamapperQuery.java
A sandbox/jdobackend/src/org/apache/roller/business/datamapper/
DatamapperPersistenceStrategy.java
A sandbox/jdobackend/src/org/apache/roller/business/datamapper/
DatamapperPropertiesManagerImpl.java
A sandbox/jdobackend/src/org/apache/roller/business/datamapper/
DatamapperReferrerManagerImpl.java
A sandbox/jdobackend/src/org/apache/roller/business/datamapper/
DatamapperUserManagerImpl.java
A sandbox/jdobackend/src/org/apache/roller/business/datamapper/
DatamapperWeblogManagerImpl.java
A sandbox/jdobackend/src/org/apache/roller/business/datamapper/
DatamapperPingQueueManagerImpl.java
Plus a JDO implementation of the Roller.
> It was my understanding that you were basically planning to provide
> some kind of generic implementation of all of the XXXManager
> interfaces which would use the Datamapper.
Right. See above.
> So presumably someone doing a backend implementation only needs to
> extend the generic manager implementations to fill out extra
> methods, plus do a Datamapper implementation.
Actually, just a Roller and DatamapperPersistenceStrategy
implementation, including writing the named queries (about 100 as I
recall).
>
> Is that right? Also, is the Datamapper only for queries? or are
> you planning for this to include all persistence operations
> including write operations?
It includes everything. Here's what I have so far...
public interface DatamapperPersistenceStrategy {
/**
* Flush changes to the datastore, commit transaction, release pm.
* @throws org.apache.roller.RollerException on any error
*/
void flush()
throws RollerException;
/**
* Release database session, rolls back any uncommitted changes.
*/
void release();
/**
* Store object in the database. Start a transaction if no
* transaction in progress.
* @param obj the object to persist
* @return the object persisted
* @throws org.apache.roller.RollerException on any error
*/
PersistentObject store(PersistentObject obj)
throws RollerException;
/**
* Remove object from persistence storage. Start a transaction
if no
* transaction in progress.
* @param clazz the class of object to remove
* @param id the id of the object to remove
* @throws RollerException on any error deleting object
*/
public void remove(Class clazz, String id)
throws RollerException;
/**
* Remove object from persistence storage. Start a transaction
if no
* transaction in progress.
* @param po the persistent object to remove
* @throws org.apache.roller.RollerException on any error
*/
public void remove(PersistentObject po)
throws RollerException;
/**
* Remove objects from persistence storage. Start a transaction
if no
* transaction in progress.
* @param pos the persistent objects to remove
* @throws org.apache.roller.RollerException on any error
*/
public void removeAll(Collection pos)
throws RollerException;
/**
* Remove objects from persistence storage. Start a transaction
if no
* transaction in progress.
* @param clazz the persistent from which to remove all objects
* @throws org.apache.roller.RollerException on any error
*/
public void removeAll(Class clazz)
throws RollerException;
/**
* Retrieve object, no transaction needed.
* @param clazz the class of object to retrieve
* @param id the id of the object to retrieve
* @return the object retrieved
* @throws RollerException on any error retrieving object
*/
public PersistentObject load(Class clazz, String id)
throws RollerException;
/**
* 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;
}
Hope this gives the detail you need...
Craig
>
>
>> 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});
>> }
>
> both of those make sense to me.
>
>
>> 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);
>> }
>
> this seems like it could be a very complex undertaking to me and
> doesn't it seem like we would be reinventing the wheel a bit?
> Hibernate already provides a very elaborate Query interface which
> you are basically proposing we try and duplicate.
>
> in any case, i don't understand the removeAll() methods, how are
> they supposed to work?
>
> -- Allen
>
>
>> Craig Russell
>> clr@apache.org http://db.apache.org/jdo
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Query interface for Datamapper
Posted by Craig L Russell <Cr...@Sun.COM>.
Sorry, missed the last part of your comments earlier...
On Aug 16, 2006, at 7:38 PM, Allen Gilliland wrote:
> this seems like it could be a very complex undertaking to me and
> doesn't it seem like we would be reinventing the wheel a bit?
Yes, a bit. I discussed with Dave how to do a "criteria query" but
then we're really inventing another wheel. I take advantage of the
fact that all of the persistence providers offer a named query
facility and then basically you provide the parameters, possibly
parameter types if the types are temporal (I never understood this
requirement but apparently it's needed for JPA portability). The
Query interface is supposed to be a trivial wrapper around the back
end query facility.
> Hibernate already provides a very elaborate Query interface which
> you are basically proposing we try and duplicate.
Actually, no. The query interface here is actually oriented toward a
named query + execute that accommodates the different styles of JPA
and JDO (and Hibernate, although that's not really at issue here).
>
> in any case, i don't understand the removeAll() methods, how are
> they supposed to work?
They are supposed to delete all instances that satisfy the query
expression. In JPA this would translate to a DELETE query.
Craig
>
> -- Allen
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Query interface for Datamapper
Posted by Allen Gilliland <al...@sun.com>.
comments inline ...
Craig L Russell wrote:
> Hi,
>
> Here's what I propose as a starting point for the query interface
> between Datamapper Managers and Datamapper Persistence.
This already confuses me. Exactly how much stuff are we adding? It was
my understanding that you were basically planning to provide some kind
of generic implementation of all of the XXXManager interfaces which
would use the Datamapper. So presumably someone doing a backend
implementation only needs to extend the generic manager implementations
to fill out extra methods, plus do a Datamapper implementation.
Is that right? Also, is the Datamapper only for queries? or are you
planning for this to include all persistence operations including write
operations?
>
> 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});
> }
both of those make sense to me.
>
> 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);
> }
this seems like it could be a very complex undertaking to me and doesn't
it seem like we would be reinventing the wheel a bit? Hibernate already
provides a very elaborate Query interface which you are basically
proposing we try and duplicate.
in any case, i don't understand the removeAll() methods, how are they
supposed to work?
-- Allen
>
> Craig Russell
> clr@apache.org http://db.apache.org/jdo
>
>
Re: Query interface for Datamapper
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Anil,
On Aug 15, 2006, at 11:31 PM, Anil Gangolli wrote:
> comments inline
>
> ----- Original Message -----
> From: Craig L Russell
> To: roller-dev@incubator.apache.org
> Sent: Tuesday, August 15, 2006 11:21 AM
> Subject: Query interface for Datamapper
>
>
> 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 interface 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;
> }
> This confused me. Shouldn't this be an interface? Wouldn't each
> persistence strategy be a factory implementing this interface ?
Doh! Copy/paste error. Of course DatamapperPersistenceStrategy is an
interface, implemented by the various back end classes. I've
corrected it above so it's clear for future discussions.
>
>
>
> 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});
> }
>
> OK. I got the pattern here. And here you do exactly what I
> thought you would, using the strategy as the factory implementation.
>
> The earlier idea was to use just say "strategy.getWebsiteByHandle
> (handle, enabled)", defining each such method on a
> PersistenceStrategy interface and implementing them in each
> strategy. This would probably turn out to make the strategy class
> huge and unwieldy, but there might be a typesafe alternative
I started out thinking the same, but it turned out that most of the
implementation of strategy.getWebsiteByHandle was the same as the
inline code, and it boiled down to calling or constructing a query.
So most of the code simply shifted from the Manager classes to the
Strategy class and indeed it became unwieldy.
Craig
>
>
>
>
>
>
> 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
> clr@apache.org http://db.apache.org/jdo
>
>
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Query interface for Datamapper
Posted by Anil Gangolli <an...@busybuddha.org>.
comments inline
----- Original Message -----
From: Craig L Russell
To: roller-dev@incubator.apache.org
Sent: Tuesday, August 15, 2006 11:21 AM
Subject: Query interface for Datamapper
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;
}
This confused me. Shouldn't this be an interface? Wouldn't each persistence strategy be a factory implementing this interface ?
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});
}
OK. I got the pattern here. And here you do exactly what I thought you would, using the strategy as the factory implementation.
The earlier idea was to use just say "strategy.getWebsiteByHandle(handle, enabled)", defining each such method on a PersistenceStrategy interface and implementing them in each strategy. This would probably turn out to make the strategy class huge and unwieldy, but there might be a typesafe alternative
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
clr@apache.org http://db.apache.org/jdo
Re: New roller persistence implementation (was Re: Query interface
for Datamapper)
Posted by Elias Torres <el...@torrez.us>.
Jeffrey Blattman wrote:
> i think i disagree. i meant users as in the folks that download roller
> binaries and deploy them. they should care that it performs, that it's
> stable, etc ... but they shouldn't care how roller achieves that. JDO
> vs. hibernate vs. JPA is an implementation detail.
Amen.
>
> (okay, for things like licensing issues, then the deployer cares.)
>
> on the other hand, developers care about this choice because it
> determines whether they can meet the performance and stability goals and
> also how effective they can be implementing new features and fixing bugs.
Absolutely.
>
> my $0.02. i'll shut up now.
Please don't.
>
> Elias Torres wrote:
>> You are right Jeffrey that *end-users* (bloggers) shouldn't care as long
>> as it works and is free to them. However, deployers may have to think
>> about their system uses Hibernate or JDO. At IBM we have to think about
>> the choice besides performance and stability.
>>
>> -Elias
>>
>> Jeffrey Blattman wrote:
>>
>>> if *users* care about whether the system uses hibernate or JDO, then
>>> they are thinking too much :) seriously though, if they have database
>>> pluggability that should be enough. they ought to be thinking about
>>> whether it performs, whether it is stable, etc.
>>>
>>> paksegu wrote:
>>>
>>>> Two Issues facing Roller
>>>> A large Roller Customer who prefers Hibernate. The need
>>>> to satisfy Apache Software license requirement for it to remain an
>>>> Apache project. Implementation can be either JDO or JPA.
>>>> It may see logical to implement both solutions by letting
>>>> Customers and Developers who prefer Hibernate to continue to do so and
>>>> distribute the Hibernate version via www.Java.net, and developers
>>>> feeling the need to satisfy Apache Software requirements choose either
>>>> JDO or JPA to implement. This will seem an extra work but it will be
>>>> great for Roller if everyone if free to implement their form of
>>>> persistent technology.
>>>> Matt Raible <mr...@gmail.com> wrote:
>>>>
>>>> On 8/15/06, Allen Gilliland wrote:
>>>>
>>>>
>>>>> 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. 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.
>>>>>
>>>> I don't believe that "everyone wants to do so" is an accurate
>>>> statement. I believe "Apache wants us to do so" is an accurate
>>>> statement. I'd rather stick with Hibernate b/c it's been proven to
>>>> work and I know it well. Remember all the issues we used to
>>>> experience on JRoller? I'd hate to see any of those come back again.
>>>>
>>>> Matt
>>>>
>>>>
>>>>
>>>>> -- 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
>>>>>> clr@apache.org http://db.apache.org/jdo
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>> Ransford Segu-Baffoe
>>>>
>>>> paksegu@yahoo.com
>>>> paksegu@noqturnalmediasystems.com
>>>>
>>>> http://www.noqturnalmediasystems.com/
>>>> http://www.noqturnalmediasystems.com/Serenade/
>>>> https://serenade.dev.java.net/
>>>> ---------------------------------
>>>> Do you Yahoo!?
>>>> Get on board. You're invited to try the new Yahoo! Mail Beta.
>>>>
>>>>
>
Re: New roller persistence implementation (was Re: Query interface for
Datamapper)
Posted by Jeffrey Blattman <Je...@Sun.COM>.
i think i disagree. i meant users as in the folks that download roller
binaries and deploy them. they should care that it performs, that it's
stable, etc ... but they shouldn't care how roller achieves that. JDO
vs. hibernate vs. JPA is an implementation detail.
(okay, for things like licensing issues, then the deployer cares.)
on the other hand, developers care about this choice because it
determines whether they can meet the performance and stability goals and
also how effective they can be implementing new features and fixing bugs.
my $0.02. i'll shut up now.
Elias Torres wrote:
> You are right Jeffrey that *end-users* (bloggers) shouldn't care as long
> as it works and is free to them. However, deployers may have to think
> about their system uses Hibernate or JDO. At IBM we have to think about
> the choice besides performance and stability.
>
> -Elias
>
> Jeffrey Blattman wrote:
>
>> if *users* care about whether the system uses hibernate or JDO, then
>> they are thinking too much :) seriously though, if they have database
>> pluggability that should be enough. they ought to be thinking about
>> whether it performs, whether it is stable, etc.
>>
>> paksegu wrote:
>>
>>> Two Issues facing Roller
>>> A large Roller Customer who prefers Hibernate. The need
>>> to satisfy Apache Software license requirement for it to remain an
>>> Apache project. Implementation can be either JDO or JPA.
>>> It may see logical to implement both solutions by letting
>>> Customers and Developers who prefer Hibernate to continue to do so and
>>> distribute the Hibernate version via www.Java.net, and developers
>>> feeling the need to satisfy Apache Software requirements choose either
>>> JDO or JPA to implement. This will seem an extra work but it will be
>>> great for Roller if everyone if free to implement their form of
>>> persistent technology.
>>>
>>> Matt Raible <mr...@gmail.com> wrote:
>>>
>>> On 8/15/06, Allen Gilliland wrote:
>>>
>>>
>>>> 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. 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.
>>>>
>>>>
>>> I don't believe that "everyone wants to do so" is an accurate
>>> statement. I believe "Apache wants us to do so" is an accurate
>>> statement. I'd rather stick with Hibernate b/c it's been proven to
>>> work and I know it well. Remember all the issues we used to
>>> experience on JRoller? I'd hate to see any of those come back again.
>>>
>>> Matt
>>>
>>>
>>>
>>>> -- 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
>>>>> clr@apache.org http://db.apache.org/jdo
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>> Ransford Segu-Baffoe
>>>
>>> paksegu@yahoo.com
>>> paksegu@noqturnalmediasystems.com
>>>
>>> http://www.noqturnalmediasystems.com/
>>> http://www.noqturnalmediasystems.com/Serenade/
>>> https://serenade.dev.java.net/
>>>
>>> ---------------------------------
>>> Do you Yahoo!?
>>> Get on board. You're invited to try the new Yahoo! Mail Beta.
>>>
>>>
>>>
Re: New roller persistence implementation (was Re: Query interface
for Datamapper)
Posted by Elias Torres <el...@torrez.us>.
You are right Jeffrey that *end-users* (bloggers) shouldn't care as long
as it works and is free to them. However, deployers may have to think
about their system uses Hibernate or JDO. At IBM we have to think about
the choice besides performance and stability.
-Elias
Jeffrey Blattman wrote:
> if *users* care about whether the system uses hibernate or JDO, then
> they are thinking too much :) seriously though, if they have database
> pluggability that should be enough. they ought to be thinking about
> whether it performs, whether it is stable, etc.
>
> paksegu wrote:
>> Two Issues facing Roller
>> A large Roller Customer who prefers Hibernate. The need
>> to satisfy Apache Software license requirement for it to remain an
>> Apache project. Implementation can be either JDO or JPA.
>> It may see logical to implement both solutions by letting
>> Customers and Developers who prefer Hibernate to continue to do so and
>> distribute the Hibernate version via www.Java.net, and developers
>> feeling the need to satisfy Apache Software requirements choose either
>> JDO or JPA to implement. This will seem an extra work but it will be
>> great for Roller if everyone if free to implement their form of
>> persistent technology.
>>
>> Matt Raible <mr...@gmail.com> wrote:
>>
>> On 8/15/06, Allen Gilliland wrote:
>>
>>> 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. 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.
>>>
>>
>> I don't believe that "everyone wants to do so" is an accurate
>> statement. I believe "Apache wants us to do so" is an accurate
>> statement. I'd rather stick with Hibernate b/c it's been proven to
>> work and I know it well. Remember all the issues we used to
>> experience on JRoller? I'd hate to see any of those come back again.
>>
>> Matt
>>
>>
>>> -- 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
>>>> clr@apache.org http://db.apache.org/jdo
>>>>
>>>>
>>>>
>>
>>
>>
>> Ransford Segu-Baffoe
>>
>> paksegu@yahoo.com
>> paksegu@noqturnalmediasystems.com
>>
>> http://www.noqturnalmediasystems.com/
>> http://www.noqturnalmediasystems.com/Serenade/
>> https://serenade.dev.java.net/
>>
>> ---------------------------------
>> Do you Yahoo!?
>> Get on board. You're invited to try the new Yahoo! Mail Beta.
>>
>>
>
Re: New roller persistence implementation (was Re: Query interface for
Datamapper)
Posted by Jeffrey Blattman <Je...@Sun.COM>.
if *users* care about whether the system uses hibernate or JDO, then
they are thinking too much :) seriously though, if they have database
pluggability that should be enough. they ought to be thinking about
whether it performs, whether it is stable, etc.
paksegu wrote:
> Two Issues facing Roller
>
>
> A large Roller Customer who prefers Hibernate.
> The need to satisfy Apache Software license requirement for it to remain an Apache project. Implementation can be either JDO or JPA.
>
> It may see logical to implement both solutions by letting Customers and Developers who prefer Hibernate to continue to do so and distribute the Hibernate version via www.Java.net, and developers feeling the need to satisfy Apache Software requirements choose either JDO or JPA to implement. This will seem an extra work but it will be great for Roller if everyone if free to implement their form of persistent technology.
>
>
>
>
> Matt Raible <mr...@gmail.com> wrote:
>
> On 8/15/06, Allen Gilliland wrote:
>
>> 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. 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.
>>
>
> I don't believe that "everyone wants to do so" is an accurate
> statement. I believe "Apache wants us to do so" is an accurate
> statement. I'd rather stick with Hibernate b/c it's been proven to
> work and I know it well. Remember all the issues we used to
> experience on JRoller? I'd hate to see any of those come back again.
>
> Matt
>
>
>> -- 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
>>> clr@apache.org http://db.apache.org/jdo
>>>
>>>
>>>
>
>
>
> Ransford Segu-Baffoe
>
> paksegu@yahoo.com
> paksegu@noqturnalmediasystems.com
>
> http://www.noqturnalmediasystems.com/
> http://www.noqturnalmediasystems.com/Serenade/
> https://serenade.dev.java.net/
>
> ---------------------------------
> Do you Yahoo!?
> Get on board. You're invited to try the new Yahoo! Mail Beta.
>
>
Got a License, Buddy?
Posted by William Tribley <bi...@tribley.org>.
This sounds like a real shame. No one is even getting rich, and
Roller developers have to refactor and rethink b/c of a licensing
issue. M$ and the pay software crowd wins all of these disputes,
whatever is decided, because in the end our software becomes more and
more mediocre and complex, encouraging people to part with money to
get code with lots of features that is simple and works.
Roller developers should be able to concentrate on features, not on
writing multiple backends. The real kicker comes at install time: Joe
Sysadmin, who has average aptitude and no patience, installs Roller
and it breaks out of the box because he forgot to go get the backend
of his choice (and he knows not enough to choose, he just wants a
blog site...) from some other developer site somewhere. Tech support
requests multiply, the perception spreads slowly that Roller is hard
to install out of the box, you know how it goes!
On Aug 15, 2006, at 10:11 PM, paksegu wrote:
> Two Issues facing Roller
>
>
> A large Roller Customer who prefers Hibernate.
> The need to satisfy Apache Software license requirement for it
> to remain an Apache project. Implementation can be either JDO or JPA.
>
> It may see logical to implement both solutions by letting
> Customers and Developers who prefer Hibernate to continue to do so
> and distribute the Hibernate version via www.Java.net, and
> developers feeling the need to satisfy Apache Software requirements
> choose either JDO or JPA to implement. This will seem an extra work
> but it will be great for Roller if everyone if free to implement
> their form of persistent technology.
>
>
>
>
> Matt Raible <mr...@gmail.com> wrote:
>
> On 8/15/06, Allen Gilliland wrote:
>>
>> 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. 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.
>
> I don't believe that "everyone wants to do so" is an accurate
> statement. I believe "Apache wants us to do so" is an accurate
> statement. I'd rather stick with Hibernate b/c it's been proven to
> work and I know it well. Remember all the issues we used to
> experience on JRoller? I'd hate to see any of those come back again.
>
> Matt
Re: New roller persistence implementation (was Re: Query interface for Datamapper)
Posted by paksegu <pa...@yahoo.com>.
Two Issues facing Roller
A large Roller Customer who prefers Hibernate.
The need to satisfy Apache Software license requirement for it to remain an Apache project. Implementation can be either JDO or JPA.
It may see logical to implement both solutions by letting Customers and Developers who prefer Hibernate to continue to do so and distribute the Hibernate version via www.Java.net, and developers feeling the need to satisfy Apache Software requirements choose either JDO or JPA to implement. This will seem an extra work but it will be great for Roller if everyone if free to implement their form of persistent technology.
Matt Raible <mr...@gmail.com> wrote:
On 8/15/06, Allen Gilliland wrote:
>
> 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. 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.
I don't believe that "everyone wants to do so" is an accurate
statement. I believe "Apache wants us to do so" is an accurate
statement. I'd rather stick with Hibernate b/c it's been proven to
work and I know it well. Remember all the issues we used to
experience on JRoller? I'd hate to see any of those come back again.
Matt
>
> -- 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
> > clr@apache.org http://db.apache.org/jdo
> >
> >
>
Ransford Segu-Baffoe
paksegu@yahoo.com
paksegu@noqturnalmediasystems.com
http://www.noqturnalmediasystems.com/
http://www.noqturnalmediasystems.com/Serenade/
https://serenade.dev.java.net/
---------------------------------
Do you Yahoo!?
Get on board. You're invited to try the new Yahoo! Mail Beta.
Re: New roller persistence implementation (was Re: Query interface
for Datamapper)
Posted by Elias Torres <el...@torrez.us>.
Allen Gilliland wrote:
> comments inline ...
>
> Matt Raible wrote:
>> On 8/15/06, Allen Gilliland <al...@sun.com> wrote:
>>>
>>> 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. 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.
>>
>> I don't believe that "everyone wants to do so" is an accurate
>> statement. I believe "Apache wants us to do so" is an accurate
>> statement. I'd rather stick with Hibernate b/c it's been proven to
>> work and I know it well. Remember all the issues we used to
>> experience on JRoller? I'd hate to see any of those come back again.
We (as IBM) would also like if Roller didn't have the hibernate
dependency. It's really a thorn in our side everytime our use of Roller
comes up to talk about the Hibernate dependency with our lawyers.
However, the only reason why we are staying with Roller is because of
our desire to leave incubator stage and have all of our code using the
same license, a license that IBM is comfortable with.
>
> Actually, that's great to hear because that's exactly how I feel.
> Perhaps I had misinterpreted the previous discussions about this on the
> list because it had seemed like not too many ppl were voicing support
> for Hibernate. For my part, I am not at all interested in replacing
> Hibernate as our persistence api for the same reasons you've eluded to ...
>
> 1. Hibernate is a known quantity and many of us have some experience
> with it. I don't have any experience with JDO or JPA, so switching to
> either of those technologies means a new learning curve.
>
> 2. Potential risk. A lot can go wrong when you swap your persistence
> layer and unless there is a burning need to do so then I think it's
> worth questioning why we would want to do that. Speaking as a customer
> of Roller who runs a large site, I am very nervous about the prospect of
> switching the Roller persistence implementation.
>
> 3. Extra work. To replace it means a lot of extra work and for what
> benefit? To get around an open source licensing issue?
>
Your points are valid but as Craig noted, I don't think we have a
choice. It's not about a license issue, it's about us becoming an Apache
project for whatever benefits the Roller community decided was worth
joining for
>
> So maybe it's time to ask the question more squarely ... who wants to
> replace Hibernate as our persistence implementation?
We would like to do so.
>
> -- Allen
>
>
>>
>> Matt
>>
>>>
>>> -- 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
>>> > clr@apache.org http://db.apache.org/jdo
>>> >
>>> >
>>>
>
Re: New roller persistence implementation (was Re: Query interface
for Datamapper)
Posted by Elias Torres <el...@torrez.us>.
+1
Craig L Russell wrote:
> Hi Jeff,
>
> I would not suggest we remove the Hibernate implementation from Roller.
>
> That should not stop us from adding a datamapper persistence
> implementation, thereby removing the hard dependency on Hibernate and
> satisfying the Apache folks.
>
> Craig
>
> On Aug 15, 2006, at 5:28 PM, Jeff Blattman wrote:
>
>> given that JDO's future is unclear* (at best) and JPA is unproven*
>> (are there any robust production tested implementations yet?), i would
>> think that a "wait and see" approach would be most prudent.
>>
>> * = craig would know much better than i, i think
>>
>> i think that all things being equal it'd be better to not have the
>> hibernate dependency, but it doesn't seem like now would be the right
>> time to switch. if you're going to do this, make sure you won't be
>> contemplating it again in 6 months.
>>
>> now, if folks want to put start putting things together in sandbox, by
>> all means ... maybe by the time 3.x is ready, things will be clear
>>
>> Allen Gilliland wrote:
>>>
>>> So maybe it's time to ask the question more squarely ... who wants to
>>> replace Hibernate as our persistence implementation?
>>>
>>> -- Allen
>>>
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
Re: New roller persistence implementation (was Re: Query interface for
Datamapper)
Posted by Allen Gilliland <al...@sun.com>.
This sounds like a very sensible approach to me.
I'd actually like to get a little more clarification about what is
acceptable in terms of removing the hard dependency on Hibernate. I
remember that being mentioned once or twice before, but I'm not sure
there was ever any solid clarification.
So if we make it possible to replace Hibernate does that mean we can
then still opt to use Hibernate as the default since it's only a soft
dependency? If we have an alternative backend in the sandbox is that
enough to allow use to continue using Hibernate as the default?
can anyone offer more info on exactly what options we have with regards
to keeping Hibernate as a soft dependency?
-- Allen
Craig L Russell wrote:
> Hi Jeff,
>
> I would not suggest we remove the Hibernate implementation from Roller.
>
> That should not stop us from adding a datamapper persistence
> implementation, thereby removing the hard dependency on Hibernate and
> satisfying the Apache folks.
>
> Craig
>
> On Aug 15, 2006, at 5:28 PM, Jeff Blattman wrote:
>
>> given that JDO's future is unclear* (at best) and JPA is unproven*
>> (are there any robust production tested implementations yet?), i would
>> think that a "wait and see" approach would be most prudent.
>>
>> * = craig would know much better than i, i think
>>
>> i think that all things being equal it'd be better to not have the
>> hibernate dependency, but it doesn't seem like now would be the right
>> time to switch. if you're going to do this, make sure you won't be
>> contemplating it again in 6 months.
>>
>> now, if folks want to put start putting things together in sandbox, by
>> all means ... maybe by the time 3.x is ready, things will be clear
>>
>> Allen Gilliland wrote:
>>>
>>> So maybe it's time to ask the question more squarely ... who wants to
>>> replace Hibernate as our persistence implementation?
>>>
>>> -- Allen
>>>
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
Re: New roller persistence implementation (was Re: Query interface for
Datamapper)
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Jeff,
I would not suggest we remove the Hibernate implementation from Roller.
That should not stop us from adding a datamapper persistence
implementation, thereby removing the hard dependency on Hibernate and
satisfying the Apache folks.
Craig
On Aug 15, 2006, at 5:28 PM, Jeff Blattman wrote:
> given that JDO's future is unclear* (at best) and JPA is unproven*
> (are there any robust production tested implementations yet?), i
> would think that a "wait and see" approach would be most prudent.
>
> * = craig would know much better than i, i think
>
> i think that all things being equal it'd be better to not have the
> hibernate dependency, but it doesn't seem like now would be the
> right time to switch. if you're going to do this, make sure you
> won't be contemplating it again in 6 months.
>
> now, if folks want to put start putting things together in sandbox,
> by all means ... maybe by the time 3.x is ready, things will be clear
>
> Allen Gilliland wrote:
>>
>> So maybe it's time to ask the question more squarely ... who wants
>> to replace Hibernate as our persistence implementation?
>>
>> -- Allen
>>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Let's pick an implementation (was Re: New roller persistence implementation)
Posted by Henri Yandell <fl...@gmail.com>.
That's where I get fuzzy (and why I've taken some time to ponder a reply).
The below is my understanding of the policy, and I've talked to Cliff
a lot about it so am pretty sure I'm not saying anything incorrect. We
can't distribute LGPL, but we can decide to ship an incomplete product
that people have to actively plug the non-distributable dependencies
into (a system requirement). A more obvious example is a JVM - there
aren't any complete JVMs out there that we could ship, but every Java
project requires it.
The 'we' there is the fuzzy bit. It's described as the PMC of the
project, so that means that Roller can ship with a Hibernate system
requirement if and only if the Incubator PMC decide to do that.
So I don't know. I think we're going to need to come up with a list of
things left to do before graduation, then after finishing off as many
as we feel we want can we need to ask the PMC if we can graduate. I'll
kick that off in a different thread.
Hen
On 8/21/06, Dave Johnson <sn...@gmail.com> wrote:
> That's pretty good. We're not being forced to ditch Hibernate, but
> it's in our best interest to do so -- to make installation easier and
> to benefit the parts of the community that have problems with LGPL.
> And it seems to imply that we can graduate from the incubator in our
> current state and only bring in a new persistence layer when we (and
> the implementation) are good and ready.
>
> Or am I reading that wrong?
>
> - Dave
>
>
>
> On 8/21/06, Henri Yandell <fl...@gmail.com> wrote:
> > On 8/16/06, Dave Johnson <sn...@gmail.com> wrote:
> > > On 8/16/06, Allen Gilliland <al...@sun.com> wrote:
> > > > The first thing I would like to know is what the final apache stance is
> > > > on our use of Hibernate. Maybe it's just me, but it hasn't been totally
> > > > clear on what exactly our options are. I know that apache doesn't like
> > > > LGPL libraries, but I thought at some point there was some discussion
> > > > that we may be able to keep Hibernate in some situations. i.e. if we
> > > > were using hibernate through an open api like JPA or if there was some
> > > > form of alternative also available. In any case, I would like to get a
> > > > firm statement from apache about our options before I make any decisions
> > > > about what to do. can someone provide an official stance from apache?
> > >
> > > Yes. I would like that too. I've never seen the official Apache policy
> > > on projects shipping or depending on LGPL. Does one exist yet?
> > >
> > > I added Cliff Scmidt to the CC list.
> >
> > http://people.apache.org/~cliffs/3party.html is still as official as
> > it gets - it's 98% official though. We (everyone at the ASF) are
> > leaping in and using it. Cliff has some changes to make before
> > releasing it to www.apache, but they're not ground breaking changes as
> > far as I understand.
> >
> > LGPL policy:
> >
> > * We may not distribute LGPL licensed works.
> > * We can depend on LGPL licensed works, provided the user is aware of
> > this before using our product (forcing them to go download it from the
> > original source being the simplest and best way).
> >
> > The first is because LGPL is still the most weakly worded of the soft
> > copyleft licenses. The other main ones can be distributed, but LGPL
> > cannot.
> >
> > The second makes clearer sense if you consider the LGPL editor that
> > Roller used to ship with. After installing that as a blog server, the
> > Roller instance is still distributing that editor out to everyone and
> > so the owners of the blog server are now distributing LGPL. This may
> > or may not be something they are comfortable with.
> >
> > For a solely back-end dependency like Hibernate, distribution is only
> > going to be when somebody ships an enhanced version of Roller - which
> > isn't as unlikely as it sounds given that Roller seems to be doing
> > well in the enterprise in-house market.
> >
> > So officially - the choice for Apache Roller is between shipping
> > without a persistence layer and having the user add it later; and
> > finding a new persistence API.
> >
> > As it's a new policy, there's always a chance that the former for the
> > long term would incite community-wide unhappiness - it's hard to get a
> > consensus for what the consensus is on soft-copyleft licenses.
> >
> > Hen
> >
>
Re: Let's pick an implementation (was Re: New roller persistence implementation)
Posted by Dave Lindsey <dl...@gmail.com>.
Sure, if you like a lowest-common-denominator solution. But it doesn't
matter, these guys are sold on the coming Apache inplementation.
On 8/21/06, paksegu <pa...@yahoo.com> wrote:
>
> Yes but using JPA as a persitent layer gives you the flexibility to use
> other data
> store technologies like (Hibernate, JPOX and etc)
>
> Dave Lindsey <dl...@gmail.com> wrote: JPA is less flexable and
> apparently only a subset of what is available in
> JPOX.
>
> http://www.jpox.org/docs/1_2/jdovsjpa.html
>
> On 8/21/06, paksegu
> wrote:
> >
> > From what I read JPA can be used as the persistent layer for Hibernate,
> > JPOX and as well as EJB 3.
> >
> > Dave Lindsey wrote: Seems like performance should
> > be considered, not to mention using a
> > standards-based solution.
> >
> > http://www.jpox.org/docs/performance.html
> >
> >
> >
> > Ransford Segu-Baffoe
> >
> > paksegu@yahoo.com
> > paksegu@noqturnalmediasystems.com
> >
> > http://www.noqturnalmediasystems.com/
> > http://www.noqturnalmediasystems.com/Serenade/
> > https://serenade.dev.java.net/
> >
> > ---------------------------------
> > Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+
> > countries) for 2ยข/min or less.
> >
>
>
>
>
> Ransford Segu-Baffoe
>
> paksegu@yahoo.com
> paksegu@noqturnalmediasystems.com
>
> http://www.noqturnalmediasystems.com/
> http://www.noqturnalmediasystems.com/Serenade/
> https://serenade.dev.java.net/
>
> ---------------------------------
> Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+
> countries) for 2ยข/min or less.
>
Re: Let's pick an implementation (was Re: New roller persistence implementation)
Posted by paksegu <pa...@yahoo.com>.
Yes but using JPA as a persitent layer gives you the flexibility to use other data
store technologies like (Hibernate, JPOX and etc)
Dave Lindsey <dl...@gmail.com> wrote: JPA is less flexable and apparently only a subset of what is available in
JPOX.
http://www.jpox.org/docs/1_2/jdovsjpa.html
On 8/21/06, paksegu
wrote:
>
> From what I read JPA can be used as the persistent layer for Hibernate,
> JPOX and as well as EJB 3.
>
> Dave Lindsey wrote: Seems like performance should
> be considered, not to mention using a
> standards-based solution.
>
> http://www.jpox.org/docs/performance.html
>
>
>
> Ransford Segu-Baffoe
>
> paksegu@yahoo.com
> paksegu@noqturnalmediasystems.com
>
> http://www.noqturnalmediasystems.com/
> http://www.noqturnalmediasystems.com/Serenade/
> https://serenade.dev.java.net/
>
> ---------------------------------
> Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+
> countries) for 2ยข/min or less.
>
Ransford Segu-Baffoe
paksegu@yahoo.com
paksegu@noqturnalmediasystems.com
http://www.noqturnalmediasystems.com/
http://www.noqturnalmediasystems.com/Serenade/
https://serenade.dev.java.net/
---------------------------------
Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2ยข/min or less.
Re: Let's pick an implementation (was Re: New roller persistence implementation)
Posted by Dave Lindsey <dl...@gmail.com>.
JPA is less flexable and apparently only a subset of what is available in
JPOX.
http://www.jpox.org/docs/1_2/jdovsjpa.html
On 8/21/06, paksegu <pa...@yahoo.com> wrote:
>
> From what I read JPA can be used as the persistent layer for Hibernate,
> JPOX and as well as EJB 3.
>
> Dave Lindsey <dl...@gmail.com> wrote: Seems like performance should
> be considered, not to mention using a
> standards-based solution.
>
> http://www.jpox.org/docs/performance.html
>
>
>
> Ransford Segu-Baffoe
>
> paksegu@yahoo.com
> paksegu@noqturnalmediasystems.com
>
> http://www.noqturnalmediasystems.com/
> http://www.noqturnalmediasystems.com/Serenade/
> https://serenade.dev.java.net/
>
> ---------------------------------
> Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+
> countries) for 2ยข/min or less.
>
Re: Let's pick an implementation (was Re: New roller persistence implementation)
Posted by paksegu <pa...@yahoo.com>.
>From what I read JPA can be used as the persistent layer for Hibernate, JPOX and as well as EJB 3.
Dave Lindsey <dl...@gmail.com> wrote: Seems like performance should be considered, not to mention using a
standards-based solution.
http://www.jpox.org/docs/performance.html
Ransford Segu-Baffoe
paksegu@yahoo.com
paksegu@noqturnalmediasystems.com
http://www.noqturnalmediasystems.com/
http://www.noqturnalmediasystems.com/Serenade/
https://serenade.dev.java.net/
---------------------------------
Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2ยข/min or less.
Re: Let's pick an implementation (was Re: New roller persistence implementation)
Posted by Dave Lindsey <dl...@gmail.com>.
Seems like performance should be considered, not to mention using a
standards-based solution.
http://www.jpox.org/docs/performance.html
Re: Let's pick an implementation (was Re: New roller persistence implementation)
Posted by Dave Johnson <sn...@gmail.com>.
That's pretty good. We're not being forced to ditch Hibernate, but
it's in our best interest to do so -- to make installation easier and
to benefit the parts of the community that have problems with LGPL.
And it seems to imply that we can graduate from the incubator in our
current state and only bring in a new persistence layer when we (and
the implementation) are good and ready.
Or am I reading that wrong?
- Dave
On 8/21/06, Henri Yandell <fl...@gmail.com> wrote:
> On 8/16/06, Dave Johnson <sn...@gmail.com> wrote:
> > On 8/16/06, Allen Gilliland <al...@sun.com> wrote:
> > > The first thing I would like to know is what the final apache stance is
> > > on our use of Hibernate. Maybe it's just me, but it hasn't been totally
> > > clear on what exactly our options are. I know that apache doesn't like
> > > LGPL libraries, but I thought at some point there was some discussion
> > > that we may be able to keep Hibernate in some situations. i.e. if we
> > > were using hibernate through an open api like JPA or if there was some
> > > form of alternative also available. In any case, I would like to get a
> > > firm statement from apache about our options before I make any decisions
> > > about what to do. can someone provide an official stance from apache?
> >
> > Yes. I would like that too. I've never seen the official Apache policy
> > on projects shipping or depending on LGPL. Does one exist yet?
> >
> > I added Cliff Scmidt to the CC list.
>
> http://people.apache.org/~cliffs/3party.html is still as official as
> it gets - it's 98% official though. We (everyone at the ASF) are
> leaping in and using it. Cliff has some changes to make before
> releasing it to www.apache, but they're not ground breaking changes as
> far as I understand.
>
> LGPL policy:
>
> * We may not distribute LGPL licensed works.
> * We can depend on LGPL licensed works, provided the user is aware of
> this before using our product (forcing them to go download it from the
> original source being the simplest and best way).
>
> The first is because LGPL is still the most weakly worded of the soft
> copyleft licenses. The other main ones can be distributed, but LGPL
> cannot.
>
> The second makes clearer sense if you consider the LGPL editor that
> Roller used to ship with. After installing that as a blog server, the
> Roller instance is still distributing that editor out to everyone and
> so the owners of the blog server are now distributing LGPL. This may
> or may not be something they are comfortable with.
>
> For a solely back-end dependency like Hibernate, distribution is only
> going to be when somebody ships an enhanced version of Roller - which
> isn't as unlikely as it sounds given that Roller seems to be doing
> well in the enterprise in-house market.
>
> So officially - the choice for Apache Roller is between shipping
> without a persistence layer and having the user add it later; and
> finding a new persistence API.
>
> As it's a new policy, there's always a chance that the former for the
> long term would incite community-wide unhappiness - it's hard to get a
> consensus for what the consensus is on soft-copyleft licenses.
>
> Hen
>
Re: Let's pick an implementation (was Re: New roller persistence implementation)
Posted by Henri Yandell <fl...@gmail.com>.
On 8/16/06, Dave Johnson <sn...@gmail.com> wrote:
> On 8/16/06, Allen Gilliland <al...@sun.com> wrote:
> > The first thing I would like to know is what the final apache stance is
> > on our use of Hibernate. Maybe it's just me, but it hasn't been totally
> > clear on what exactly our options are. I know that apache doesn't like
> > LGPL libraries, but I thought at some point there was some discussion
> > that we may be able to keep Hibernate in some situations. i.e. if we
> > were using hibernate through an open api like JPA or if there was some
> > form of alternative also available. In any case, I would like to get a
> > firm statement from apache about our options before I make any decisions
> > about what to do. can someone provide an official stance from apache?
>
> Yes. I would like that too. I've never seen the official Apache policy
> on projects shipping or depending on LGPL. Does one exist yet?
>
> I added Cliff Scmidt to the CC list.
http://people.apache.org/~cliffs/3party.html is still as official as
it gets - it's 98% official though. We (everyone at the ASF) are
leaping in and using it. Cliff has some changes to make before
releasing it to www.apache, but they're not ground breaking changes as
far as I understand.
LGPL policy:
* We may not distribute LGPL licensed works.
* We can depend on LGPL licensed works, provided the user is aware of
this before using our product (forcing them to go download it from the
original source being the simplest and best way).
The first is because LGPL is still the most weakly worded of the soft
copyleft licenses. The other main ones can be distributed, but LGPL
cannot.
The second makes clearer sense if you consider the LGPL editor that
Roller used to ship with. After installing that as a blog server, the
Roller instance is still distributing that editor out to everyone and
so the owners of the blog server are now distributing LGPL. This may
or may not be something they are comfortable with.
For a solely back-end dependency like Hibernate, distribution is only
going to be when somebody ships an enhanced version of Roller - which
isn't as unlikely as it sounds given that Roller seems to be doing
well in the enterprise in-house market.
So officially - the choice for Apache Roller is between shipping
without a persistence layer and having the user add it later; and
finding a new persistence API.
As it's a new policy, there's always a chance that the former for the
long term would incite community-wide unhappiness - it's hard to get a
consensus for what the consensus is on soft-copyleft licenses.
Hen
Re: Let's pick an implementation (was Re: New roller persistence implementation)
Posted by Dave Johnson <sn...@gmail.com>.
On 8/16/06, Allen Gilliland <al...@sun.com> wrote:
> The first thing I would like to know is what the final apache stance is
> on our use of Hibernate. Maybe it's just me, but it hasn't been totally
> clear on what exactly our options are. I know that apache doesn't like
> LGPL libraries, but I thought at some point there was some discussion
> that we may be able to keep Hibernate in some situations. i.e. if we
> were using hibernate through an open api like JPA or if there was some
> form of alternative also available. In any case, I would like to get a
> firm statement from apache about our options before I make any decisions
> about what to do. can someone provide an official stance from apache?
Yes. I would like that too. I've never seen the official Apache policy
on projects shipping or depending on LGPL. Does one exist yet?
I added Cliff Scmidt to the CC list.
- Dave
Re: Let's pick an implementation (was Re: New roller persistence
implementation)
Posted by Allen Gilliland <al...@sun.com>.
Dave Johnson wrote:
> On 8/16/06, Elias Torres <el...@torrez.us> wrote:
>> I think we have heard enough opinions from many in the community. Should
>> we try to vote on the issue and decide? The options are many all
>> hovering on things from the set keeping hibernate, staying at apache,
>> Sun leaving roller, IBM leaving roller, making it pluggable, replace the
>> ORM, rewrite it in Ruby, Lisp, ML and any combination of any of these.
>
> Personally, I don't see a crisis or a need for a vote.
>
> Craig would like to develop an alternative backend for Roller. I don't
> think we need to vote to permit him to do that in the sandbox or in a
> separate banch.
>
> Those that wish to help Craig suceed should help him by reviewing his
> design, suggesting improvements and assisting with implementation.
> When/if Craig and friends come up with an implementation or two we can
> evaluate it and then decide what to do -- with a vote if necessary.
That sounds good to me, but I don't think that means we should stop
discussing the issue. We still need to figure out our general approach
to this problem as a community.
The first thing I would like to know is what the final apache stance is
on our use of Hibernate. Maybe it's just me, but it hasn't been totally
clear on what exactly our options are. I know that apache doesn't like
LGPL libraries, but I thought at some point there was some discussion
that we may be able to keep Hibernate in some situations. i.e. if we
were using hibernate through an open api like JPA or if there was some
form of alternative also available. In any case, I would like to get a
firm statement from apache about our options before I make any decisions
about what to do. can someone provide an official stance from apache?
-- Allen
>
> - Dave
Re: Let's pick an implementation (was Re: New roller persistence implementation)
Posted by Dave Johnson <sn...@gmail.com>.
On 8/16/06, Elias Torres <el...@torrez.us> wrote:
> I think we have heard enough opinions from many in the community. Should
> we try to vote on the issue and decide? The options are many all
> hovering on things from the set keeping hibernate, staying at apache,
> Sun leaving roller, IBM leaving roller, making it pluggable, replace the
> ORM, rewrite it in Ruby, Lisp, ML and any combination of any of these.
Personally, I don't see a crisis or a need for a vote.
Craig would like to develop an alternative backend for Roller. I don't
think we need to vote to permit him to do that in the sandbox or in a
separate banch.
Those that wish to help Craig suceed should help him by reviewing his
design, suggesting improvements and assisting with implementation.
When/if Craig and friends come up with an implementation or two we can
evaluate it and then decide what to do -- with a vote if necessary.
- Dave
Re: Let's pick an implementation (was Re: New roller persistence
implementation)
Posted by Elias Torres <el...@torrez.us>.
Right on. Roller was part of a couple of studies at Forrester Research
and we did not fare too well. We understand why but we have faith in its
potential and would like to see it taken to a next level. The main
reason behind Roller lower ratings seem to be lack of vendor support as
opposed to iUpload, MovableType, WordPress, Blogger, etc.
This is more than just Hibernate and Apache, like you said, it's more
about what we can do in the future for our users by improving its
support and development through more resources.
Roller is definitely growing up!
-Elias
paksegu wrote:
> I am not a Developer on the Roller team so I now my inputs are somehow limited, however from a Developers standpoint it makes no sense replacing hibernate just to graduate from Apache. On the other hand, from a business standpoint it make absolute sense when you intend to create a business model out of Rolller and distribute it commercially; you will come across a costly barrier imposed by Hibernate GPL license unless your intention for Roller to be used non commercial or proprietary environment. Having the flexibility of Apache license creates more business opportunities which turns out great for Roller in respect that we can have afford to get developers to commit to the success of Roller
>
>
>
> Elias Torres <el...@torrez.us> wrote:
>
> Allen Gilliland wrote:
>> The difference is partly a shift in my viewpoint and partly a shift in
>> my intentions with each email. I never changed my opinion on my support
>> for Hibernate, but what has changed as the discussion has grown is how
>> willing I am to support the alternatives.
>>
>> First off, I should make clear that I don't speak for Sun, I speak for
>> myself and to some degree on the behalf of the team I with that is
>> responsible for running blogs.sun.com. My job is to run that website
>> and the decisions I make with regards to Roller are always influenced by
>> what I think is best for blogs.sun.com.
>>
>> I had originally been more open in my discussion about the various
>> approaches that could be taken around the persistence implementation
>> mostly because I had for one reason or another felt that folks on this
>> list had already made up their mind to replace Hibernate despite my
>> objections. Part of me thinks that's okay and I am not entirely opposed
>> to an alternate approach, but as I thought about it more realistically
>> it seems less and less like a good idea and that's where my last email
>> came from.
>>
>> You said that Hibernate is a thorn in your side, so you obviously you
>> favor replacing it, but we don't have that problem and AFAIK there
>> aren't any other Roller users who have complained about that. If we
>> don't have a problem with using Hibernate when why should we want to
>> replace it? I don't think there are any benefits at all for us to
>> replace Hibernate.
>
> That might definitely be true. The benefits to most Roller
> users/installers by us changing could at best be none, if anything it
> will be growing pains all over.
>
>> I am always open to options, but you have to tell me why we should
>> replace Hibernate? If the only reason is because of an issue with
>> apache licensing then that's not good enough in my opinion.
>
> IBM's reason is simply a license issue and so is Apache's reason. If I
> were to speak on the matter personally, this whole issue definitely
> stinks. However, as an IBM employee I have to comply with the company's
> policies and we cannot afford to be involved in licensing lawsuits and
> that's more than good enough for me in my opinion.
>
> I'm in no way advocating that we make our users deal with the pain and
> that's why I want to entertain the pluggable option. Dave's OpenJPA
> suggestion sounds plausible (as long as there's a Apache-licensed JPA
> implementation that's been proven or simply works).
>
> I think we have heard enough opinions from many in the community. Should
> we try to vote on the issue and decide? The options are many all
> hovering on things from the set keeping hibernate, staying at apache,
> Sun leaving roller, IBM leaving roller, making it pluggable, replace the
> ORM, rewrite it in Ruby, Lisp, ML and any combination of any of these.
>
> I often share at IBM that Roller Team is 100% behind solving the
> Hibernate issue by satisfying Apache Licensing requirements and every
> month or so, we seem to waver at our initial commitment to make Roller
> an Apache project all for an ORM library. We are currently at a crucial
> moment in our decision to continue working with the Roller project and
> some clarification in the matter would help us to decide whether or not
> we would get more involved with Roller than we are today.
>
> What do you guys think? Can we try to make a decision? I'm all for what
> is best for the today's and future Roller users.
>
> -Elias
>
>> -- Allen
>>
>>
>> Elias Torres wrote:
>>> Allen,
>>>
>>> I note a stark difference between this email and one of the first emails
>>> from you in the thread:
>>>
>>> """
>>> 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. 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. """
>>>
>>> Now it seems that the *only* option for you (is it for Sun, too?) is
>>> Hibernate. Is that correct? Why the change of opinion? If I may ask.
>>>
>>> -Elias
>>>
>>> Allen Gilliland wrote:
>>>> I still want more information about the soft vs. hard dependency issue
>>>> WRT Hibernate being part of the project, but whatever the outcome of
>>>> that is doesn't change the fact that I continue to support Hibernate as
>>>> our implementation.
>>>>
>>>> I should also say that depending on how this works out this is something
>>>> that could put us (blogs.sun.com) at odds with the community and
>>>> encourage us to go our own direction.
>>>>
>>>> My only concern is for my installation of Roller at blogs.sun.com and as
>>>> I've said before, switching to something other than Hibernate is only
>>>> going to create problems for us. As far as I'm concerned Hibernate
>>>> still offers the best option as the persistence implementation and since
>>>> the licensing issue does not affect us specifically then I don't see any
>>>> reason to mess with it. At some point we will likely be willing to try
>>>> a JPA implementation, but we are not really interested in being one of
>>>> the first adopters, so that won't happen for a while.
>>>>
>>>> Depending on the outcome of the soft vs. hard dependency issue and
>>>> whether or not apache will provide us some potential way to continue
>>>> using Hibernate legally is what will determine my final point of view.
>>>>
>>>> -- Allen
>>>>
>>>>
>>>> Dave Johnson wrote:
>>>>> On 8/16/06, Anil Gangolli wrote:
>>>>>> I support Elias's option #2 with some concessions to #1.
>>>>> I feel about the same way.
>>>>>
>>>>> On the question of "who here wants to replace Hibernate?"
>>>>>
>>>>> Hibernate's LGPL licensing is incompatible with Apache policy and
>>>>> there exists a set of contributors who are willing and able to provide
>>>>> an alternative backend impl. I'm a member of that set. If we create an
>>>>> alternative, it works well and we've got consensus then we'll ship it
>>>>> with Roller. Do we have to do this before we graduate? I sure as hell
>>>>> hope not.
>>>>>
>>>>> On the question of "which ORM should we choose?"
>>>>>
>>>>> I definitely believe we should ship one ORM with Roller and the Roller
>>>>> project should not do anything to promote, document or support the
>>>>> idea of users plugging in alternative ORMs.
>>>>>
>>>>> Personally I favor JPA because 1) there will be multiple high-quality
>>>>> implementatons (some at Apache) and 2) Hibernate is one of the
>>>>> implementations. So we'd ship OpenJPA or something similar, but folks
>>>>> who *really* want to continue using Hibernate can figure out on their
>>>>> own how to configure Roller to use Hibernate's JPA implementation.
>>>>>
>>>>> On the question of "Data Mapper good or bad?"
>>>>>
>>>>> I'm +1 on Data Mapper. The Data Mapper pattern allows us to abstract
>>>>> ORM queries, just as our Persistence Strategy allows us to abstract
>>>>> ORM load/save operations. We'll have a complete persistence
>>>>> abstraction, something I've always wanted to see. The ability to
>>>>> compare JPA, JDO and possibly other ORMs seems like a key feature
>>>>> right now. Having named and externalized queries is nice too.
>>>>>
>>>>> - Dave
>
>
>
> Ransford Segu-Baffoe
>
> paksegu@yahoo.com
> paksegu@noqturnalmediasystems.com
>
> http://www.noqturnalmediasystems.com/
> http://www.noqturnalmediasystems.com/Serenade/
> https://serenade.dev.java.net/
>
> ---------------------------------
> Do you Yahoo!?
> Get on board. You're invited to try the new Yahoo! Mail Beta.
Re: Let's pick an implementation (was Re: New roller persistence implementation)
Posted by paksegu <pa...@yahoo.com>.
I am not a Developer on the Roller team so I now my inputs are somehow limited, however from a Developers standpoint it makes no sense replacing hibernate just to graduate from Apache. On the other hand, from a business standpoint it make absolute sense when you intend to create a business model out of Rolller and distribute it commercially; you will come across a costly barrier imposed by Hibernate GPL license unless your intention for Roller to be used non commercial or proprietary environment. Having the flexibility of Apache license creates more business opportunities which turns out great for Roller in respect that we can have afford to get developers to commit to the success of Roller
Elias Torres <el...@torrez.us> wrote:
Allen Gilliland wrote:
> The difference is partly a shift in my viewpoint and partly a shift in
> my intentions with each email. I never changed my opinion on my support
> for Hibernate, but what has changed as the discussion has grown is how
> willing I am to support the alternatives.
>
> First off, I should make clear that I don't speak for Sun, I speak for
> myself and to some degree on the behalf of the team I with that is
> responsible for running blogs.sun.com. My job is to run that website
> and the decisions I make with regards to Roller are always influenced by
> what I think is best for blogs.sun.com.
>
> I had originally been more open in my discussion about the various
> approaches that could be taken around the persistence implementation
> mostly because I had for one reason or another felt that folks on this
> list had already made up their mind to replace Hibernate despite my
> objections. Part of me thinks that's okay and I am not entirely opposed
> to an alternate approach, but as I thought about it more realistically
> it seems less and less like a good idea and that's where my last email
> came from.
>
> You said that Hibernate is a thorn in your side, so you obviously you
> favor replacing it, but we don't have that problem and AFAIK there
> aren't any other Roller users who have complained about that. If we
> don't have a problem with using Hibernate when why should we want to
> replace it? I don't think there are any benefits at all for us to
> replace Hibernate.
That might definitely be true. The benefits to most Roller
users/installers by us changing could at best be none, if anything it
will be growing pains all over.
>
> I am always open to options, but you have to tell me why we should
> replace Hibernate? If the only reason is because of an issue with
> apache licensing then that's not good enough in my opinion.
IBM's reason is simply a license issue and so is Apache's reason. If I
were to speak on the matter personally, this whole issue definitely
stinks. However, as an IBM employee I have to comply with the company's
policies and we cannot afford to be involved in licensing lawsuits and
that's more than good enough for me in my opinion.
I'm in no way advocating that we make our users deal with the pain and
that's why I want to entertain the pluggable option. Dave's OpenJPA
suggestion sounds plausible (as long as there's a Apache-licensed JPA
implementation that's been proven or simply works).
I think we have heard enough opinions from many in the community. Should
we try to vote on the issue and decide? The options are many all
hovering on things from the set keeping hibernate, staying at apache,
Sun leaving roller, IBM leaving roller, making it pluggable, replace the
ORM, rewrite it in Ruby, Lisp, ML and any combination of any of these.
I often share at IBM that Roller Team is 100% behind solving the
Hibernate issue by satisfying Apache Licensing requirements and every
month or so, we seem to waver at our initial commitment to make Roller
an Apache project all for an ORM library. We are currently at a crucial
moment in our decision to continue working with the Roller project and
some clarification in the matter would help us to decide whether or not
we would get more involved with Roller than we are today.
What do you guys think? Can we try to make a decision? I'm all for what
is best for the today's and future Roller users.
-Elias
>
> -- Allen
>
>
> Elias Torres wrote:
>> Allen,
>>
>> I note a stark difference between this email and one of the first emails
>> from you in the thread:
>>
>> """
>> 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. 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. """
>>
>> Now it seems that the *only* option for you (is it for Sun, too?) is
>> Hibernate. Is that correct? Why the change of opinion? If I may ask.
>>
>> -Elias
>>
>> Allen Gilliland wrote:
>>> I still want more information about the soft vs. hard dependency issue
>>> WRT Hibernate being part of the project, but whatever the outcome of
>>> that is doesn't change the fact that I continue to support Hibernate as
>>> our implementation.
>>>
>>> I should also say that depending on how this works out this is something
>>> that could put us (blogs.sun.com) at odds with the community and
>>> encourage us to go our own direction.
>>>
>>> My only concern is for my installation of Roller at blogs.sun.com and as
>>> I've said before, switching to something other than Hibernate is only
>>> going to create problems for us. As far as I'm concerned Hibernate
>>> still offers the best option as the persistence implementation and since
>>> the licensing issue does not affect us specifically then I don't see any
>>> reason to mess with it. At some point we will likely be willing to try
>>> a JPA implementation, but we are not really interested in being one of
>>> the first adopters, so that won't happen for a while.
>>>
>>> Depending on the outcome of the soft vs. hard dependency issue and
>>> whether or not apache will provide us some potential way to continue
>>> using Hibernate legally is what will determine my final point of view.
>>>
>>> -- Allen
>>>
>>>
>>> Dave Johnson wrote:
>>>> On 8/16/06, Anil Gangolli wrote:
>>>>> I support Elias's option #2 with some concessions to #1.
>>>> I feel about the same way.
>>>>
>>>> On the question of "who here wants to replace Hibernate?"
>>>>
>>>> Hibernate's LGPL licensing is incompatible with Apache policy and
>>>> there exists a set of contributors who are willing and able to provide
>>>> an alternative backend impl. I'm a member of that set. If we create an
>>>> alternative, it works well and we've got consensus then we'll ship it
>>>> with Roller. Do we have to do this before we graduate? I sure as hell
>>>> hope not.
>>>>
>>>> On the question of "which ORM should we choose?"
>>>>
>>>> I definitely believe we should ship one ORM with Roller and the Roller
>>>> project should not do anything to promote, document or support the
>>>> idea of users plugging in alternative ORMs.
>>>>
>>>> Personally I favor JPA because 1) there will be multiple high-quality
>>>> implementatons (some at Apache) and 2) Hibernate is one of the
>>>> implementations. So we'd ship OpenJPA or something similar, but folks
>>>> who *really* want to continue using Hibernate can figure out on their
>>>> own how to configure Roller to use Hibernate's JPA implementation.
>>>>
>>>> On the question of "Data Mapper good or bad?"
>>>>
>>>> I'm +1 on Data Mapper. The Data Mapper pattern allows us to abstract
>>>> ORM queries, just as our Persistence Strategy allows us to abstract
>>>> ORM load/save operations. We'll have a complete persistence
>>>> abstraction, something I've always wanted to see. The ability to
>>>> compare JPA, JDO and possibly other ORMs seems like a key feature
>>>> right now. Having named and externalized queries is nice too.
>>>>
>>>> - Dave
>
Ransford Segu-Baffoe
paksegu@yahoo.com
paksegu@noqturnalmediasystems.com
http://www.noqturnalmediasystems.com/
http://www.noqturnalmediasystems.com/Serenade/
https://serenade.dev.java.net/
---------------------------------
Do you Yahoo!?
Get on board. You're invited to try the new Yahoo! Mail Beta.
Re: Let's pick an implementation (was Re: New roller persistence
implementation)
Posted by Elias Torres <el...@torrez.us>.
Allen Gilliland wrote:
> The difference is partly a shift in my viewpoint and partly a shift in
> my intentions with each email. I never changed my opinion on my support
> for Hibernate, but what has changed as the discussion has grown is how
> willing I am to support the alternatives.
>
> First off, I should make clear that I don't speak for Sun, I speak for
> myself and to some degree on the behalf of the team I with that is
> responsible for running blogs.sun.com. My job is to run that website
> and the decisions I make with regards to Roller are always influenced by
> what I think is best for blogs.sun.com.
>
> I had originally been more open in my discussion about the various
> approaches that could be taken around the persistence implementation
> mostly because I had for one reason or another felt that folks on this
> list had already made up their mind to replace Hibernate despite my
> objections. Part of me thinks that's okay and I am not entirely opposed
> to an alternate approach, but as I thought about it more realistically
> it seems less and less like a good idea and that's where my last email
> came from.
>
> You said that Hibernate is a thorn in your side, so you obviously you
> favor replacing it, but we don't have that problem and AFAIK there
> aren't any other Roller users who have complained about that. If we
> don't have a problem with using Hibernate when why should we want to
> replace it? I don't think there are any benefits at all for us to
> replace Hibernate.
That might definitely be true. The benefits to most Roller
users/installers by us changing could at best be none, if anything it
will be growing pains all over.
>
> I am always open to options, but you have to tell me why we should
> replace Hibernate? If the only reason is because of an issue with
> apache licensing then that's not good enough in my opinion.
IBM's reason is simply a license issue and so is Apache's reason. If I
were to speak on the matter personally, this whole issue definitely
stinks. However, as an IBM employee I have to comply with the company's
policies and we cannot afford to be involved in licensing lawsuits and
that's more than good enough for me in my opinion.
I'm in no way advocating that we make our users deal with the pain and
that's why I want to entertain the pluggable option. Dave's OpenJPA
suggestion sounds plausible (as long as there's a Apache-licensed JPA
implementation that's been proven or simply works).
I think we have heard enough opinions from many in the community. Should
we try to vote on the issue and decide? The options are many all
hovering on things from the set keeping hibernate, staying at apache,
Sun leaving roller, IBM leaving roller, making it pluggable, replace the
ORM, rewrite it in Ruby, Lisp, ML and any combination of any of these.
I often share at IBM that Roller Team is 100% behind solving the
Hibernate issue by satisfying Apache Licensing requirements and every
month or so, we seem to waver at our initial commitment to make Roller
an Apache project all for an ORM library. We are currently at a crucial
moment in our decision to continue working with the Roller project and
some clarification in the matter would help us to decide whether or not
we would get more involved with Roller than we are today.
What do you guys think? Can we try to make a decision? I'm all for what
is best for the today's and future Roller users.
-Elias
>
> -- Allen
>
>
> Elias Torres wrote:
>> Allen,
>>
>> I note a stark difference between this email and one of the first emails
>> from you in the thread:
>>
>> """
>> 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. 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. """
>>
>> Now it seems that the *only* option for you (is it for Sun, too?) is
>> Hibernate. Is that correct? Why the change of opinion? If I may ask.
>>
>> -Elias
>>
>> Allen Gilliland wrote:
>>> I still want more information about the soft vs. hard dependency issue
>>> WRT Hibernate being part of the project, but whatever the outcome of
>>> that is doesn't change the fact that I continue to support Hibernate as
>>> our implementation.
>>>
>>> I should also say that depending on how this works out this is something
>>> that could put us (blogs.sun.com) at odds with the community and
>>> encourage us to go our own direction.
>>>
>>> My only concern is for my installation of Roller at blogs.sun.com and as
>>> I've said before, switching to something other than Hibernate is only
>>> going to create problems for us. As far as I'm concerned Hibernate
>>> still offers the best option as the persistence implementation and since
>>> the licensing issue does not affect us specifically then I don't see any
>>> reason to mess with it. At some point we will likely be willing to try
>>> a JPA implementation, but we are not really interested in being one of
>>> the first adopters, so that won't happen for a while.
>>>
>>> Depending on the outcome of the soft vs. hard dependency issue and
>>> whether or not apache will provide us some potential way to continue
>>> using Hibernate legally is what will determine my final point of view.
>>>
>>> -- Allen
>>>
>>>
>>> Dave Johnson wrote:
>>>> On 8/16/06, Anil Gangolli <an...@busybuddha.org> wrote:
>>>>> I support Elias's option #2 with some concessions to #1.
>>>> I feel about the same way.
>>>>
>>>> On the question of "who here wants to replace Hibernate?"
>>>>
>>>> Hibernate's LGPL licensing is incompatible with Apache policy and
>>>> there exists a set of contributors who are willing and able to provide
>>>> an alternative backend impl. I'm a member of that set. If we create an
>>>> alternative, it works well and we've got consensus then we'll ship it
>>>> with Roller. Do we have to do this before we graduate? I sure as hell
>>>> hope not.
>>>>
>>>> On the question of "which ORM should we choose?"
>>>>
>>>> I definitely believe we should ship one ORM with Roller and the Roller
>>>> project should not do anything to promote, document or support the
>>>> idea of users plugging in alternative ORMs.
>>>>
>>>> Personally I favor JPA because 1) there will be multiple high-quality
>>>> implementatons (some at Apache) and 2) Hibernate is one of the
>>>> implementations. So we'd ship OpenJPA or something similar, but folks
>>>> who *really* want to continue using Hibernate can figure out on their
>>>> own how to configure Roller to use Hibernate's JPA implementation.
>>>>
>>>> On the question of "Data Mapper good or bad?"
>>>>
>>>> I'm +1 on Data Mapper. The Data Mapper pattern allows us to abstract
>>>> ORM queries, just as our Persistence Strategy allows us to abstract
>>>> ORM load/save operations. We'll have a complete persistence
>>>> abstraction, something I've always wanted to see. The ability to
>>>> compare JPA, JDO and possibly other ORMs seems like a key feature
>>>> right now. Having named and externalized queries is nice too.
>>>>
>>>> - Dave
>
Re: Let's pick an implementation (was Re: New roller persistence
implementation)
Posted by Allen Gilliland <al...@sun.com>.
The difference is partly a shift in my viewpoint and partly a shift in
my intentions with each email. I never changed my opinion on my support
for Hibernate, but what has changed as the discussion has grown is how
willing I am to support the alternatives.
First off, I should make clear that I don't speak for Sun, I speak for
myself and to some degree on the behalf of the team I with that is
responsible for running blogs.sun.com. My job is to run that website
and the decisions I make with regards to Roller are always influenced by
what I think is best for blogs.sun.com.
I had originally been more open in my discussion about the various
approaches that could be taken around the persistence implementation
mostly because I had for one reason or another felt that folks on this
list had already made up their mind to replace Hibernate despite my
objections. Part of me thinks that's okay and I am not entirely opposed
to an alternate approach, but as I thought about it more realistically
it seems less and less like a good idea and that's where my last email
came from.
You said that Hibernate is a thorn in your side, so you obviously you
favor replacing it, but we don't have that problem and AFAIK there
aren't any other Roller users who have complained about that. If we
don't have a problem with using Hibernate when why should we want to
replace it? I don't think there are any benefits at all for us to
replace Hibernate.
I am always open to options, but you have to tell me why we should
replace Hibernate? If the only reason is because of an issue with
apache licensing then that's not good enough in my opinion.
-- Allen
Elias Torres wrote:
> Allen,
>
> I note a stark difference between this email and one of the first emails
> from you in the thread:
>
> """
> 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. 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. """
>
> Now it seems that the *only* option for you (is it for Sun, too?) is
> Hibernate. Is that correct? Why the change of opinion? If I may ask.
>
> -Elias
>
> Allen Gilliland wrote:
>> I still want more information about the soft vs. hard dependency issue
>> WRT Hibernate being part of the project, but whatever the outcome of
>> that is doesn't change the fact that I continue to support Hibernate as
>> our implementation.
>>
>> I should also say that depending on how this works out this is something
>> that could put us (blogs.sun.com) at odds with the community and
>> encourage us to go our own direction.
>>
>> My only concern is for my installation of Roller at blogs.sun.com and as
>> I've said before, switching to something other than Hibernate is only
>> going to create problems for us. As far as I'm concerned Hibernate
>> still offers the best option as the persistence implementation and since
>> the licensing issue does not affect us specifically then I don't see any
>> reason to mess with it. At some point we will likely be willing to try
>> a JPA implementation, but we are not really interested in being one of
>> the first adopters, so that won't happen for a while.
>>
>> Depending on the outcome of the soft vs. hard dependency issue and
>> whether or not apache will provide us some potential way to continue
>> using Hibernate legally is what will determine my final point of view.
>>
>> -- Allen
>>
>>
>> Dave Johnson wrote:
>>> On 8/16/06, Anil Gangolli <an...@busybuddha.org> wrote:
>>>> I support Elias's option #2 with some concessions to #1.
>>> I feel about the same way.
>>>
>>> On the question of "who here wants to replace Hibernate?"
>>>
>>> Hibernate's LGPL licensing is incompatible with Apache policy and
>>> there exists a set of contributors who are willing and able to provide
>>> an alternative backend impl. I'm a member of that set. If we create an
>>> alternative, it works well and we've got consensus then we'll ship it
>>> with Roller. Do we have to do this before we graduate? I sure as hell
>>> hope not.
>>>
>>> On the question of "which ORM should we choose?"
>>>
>>> I definitely believe we should ship one ORM with Roller and the Roller
>>> project should not do anything to promote, document or support the
>>> idea of users plugging in alternative ORMs.
>>>
>>> Personally I favor JPA because 1) there will be multiple high-quality
>>> implementatons (some at Apache) and 2) Hibernate is one of the
>>> implementations. So we'd ship OpenJPA or something similar, but folks
>>> who *really* want to continue using Hibernate can figure out on their
>>> own how to configure Roller to use Hibernate's JPA implementation.
>>>
>>> On the question of "Data Mapper good or bad?"
>>>
>>> I'm +1 on Data Mapper. The Data Mapper pattern allows us to abstract
>>> ORM queries, just as our Persistence Strategy allows us to abstract
>>> ORM load/save operations. We'll have a complete persistence
>>> abstraction, something I've always wanted to see. The ability to
>>> compare JPA, JDO and possibly other ORMs seems like a key feature
>>> right now. Having named and externalized queries is nice too.
>>>
>>> - Dave
Re: Let's pick an implementation (was Re: New roller persistence
implementation)
Posted by Elias Torres <el...@torrez.us>.
Allen,
I note a stark difference between this email and one of the first emails
from you in the thread:
"""
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. 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. """
Now it seems that the *only* option for you (is it for Sun, too?) is
Hibernate. Is that correct? Why the change of opinion? If I may ask.
-Elias
Allen Gilliland wrote:
> I still want more information about the soft vs. hard dependency issue
> WRT Hibernate being part of the project, but whatever the outcome of
> that is doesn't change the fact that I continue to support Hibernate as
> our implementation.
>
> I should also say that depending on how this works out this is something
> that could put us (blogs.sun.com) at odds with the community and
> encourage us to go our own direction.
>
> My only concern is for my installation of Roller at blogs.sun.com and as
> I've said before, switching to something other than Hibernate is only
> going to create problems for us. As far as I'm concerned Hibernate
> still offers the best option as the persistence implementation and since
> the licensing issue does not affect us specifically then I don't see any
> reason to mess with it. At some point we will likely be willing to try
> a JPA implementation, but we are not really interested in being one of
> the first adopters, so that won't happen for a while.
>
> Depending on the outcome of the soft vs. hard dependency issue and
> whether or not apache will provide us some potential way to continue
> using Hibernate legally is what will determine my final point of view.
>
> -- Allen
>
>
> Dave Johnson wrote:
>> On 8/16/06, Anil Gangolli <an...@busybuddha.org> wrote:
>>> I support Elias's option #2 with some concessions to #1.
>>
>> I feel about the same way.
>>
>> On the question of "who here wants to replace Hibernate?"
>>
>> Hibernate's LGPL licensing is incompatible with Apache policy and
>> there exists a set of contributors who are willing and able to provide
>> an alternative backend impl. I'm a member of that set. If we create an
>> alternative, it works well and we've got consensus then we'll ship it
>> with Roller. Do we have to do this before we graduate? I sure as hell
>> hope not.
>>
>> On the question of "which ORM should we choose?"
>>
>> I definitely believe we should ship one ORM with Roller and the Roller
>> project should not do anything to promote, document or support the
>> idea of users plugging in alternative ORMs.
>>
>> Personally I favor JPA because 1) there will be multiple high-quality
>> implementatons (some at Apache) and 2) Hibernate is one of the
>> implementations. So we'd ship OpenJPA or something similar, but folks
>> who *really* want to continue using Hibernate can figure out on their
>> own how to configure Roller to use Hibernate's JPA implementation.
>>
>> On the question of "Data Mapper good or bad?"
>>
>> I'm +1 on Data Mapper. The Data Mapper pattern allows us to abstract
>> ORM queries, just as our Persistence Strategy allows us to abstract
>> ORM load/save operations. We'll have a complete persistence
>> abstraction, something I've always wanted to see. The ability to
>> compare JPA, JDO and possibly other ORMs seems like a key feature
>> right now. Having named and externalized queries is nice too.
>>
>> - Dave
>
Re: Let's pick an implementation (was Re: New roller persistence
implementation)
Posted by Allen Gilliland <al...@sun.com>.
I still want more information about the soft vs. hard dependency issue
WRT Hibernate being part of the project, but whatever the outcome of
that is doesn't change the fact that I continue to support Hibernate as
our implementation.
I should also say that depending on how this works out this is something
that could put us (blogs.sun.com) at odds with the community and
encourage us to go our own direction.
My only concern is for my installation of Roller at blogs.sun.com and as
I've said before, switching to something other than Hibernate is only
going to create problems for us. As far as I'm concerned Hibernate
still offers the best option as the persistence implementation and since
the licensing issue does not affect us specifically then I don't see any
reason to mess with it. At some point we will likely be willing to try
a JPA implementation, but we are not really interested in being one of
the first adopters, so that won't happen for a while.
Depending on the outcome of the soft vs. hard dependency issue and
whether or not apache will provide us some potential way to continue
using Hibernate legally is what will determine my final point of view.
-- Allen
Dave Johnson wrote:
> On 8/16/06, Anil Gangolli <an...@busybuddha.org> wrote:
>> I support Elias's option #2 with some concessions to #1.
>
> I feel about the same way.
>
> On the question of "who here wants to replace Hibernate?"
>
> Hibernate's LGPL licensing is incompatible with Apache policy and
> there exists a set of contributors who are willing and able to provide
> an alternative backend impl. I'm a member of that set. If we create an
> alternative, it works well and we've got consensus then we'll ship it
> with Roller. Do we have to do this before we graduate? I sure as hell
> hope not.
>
> On the question of "which ORM should we choose?"
>
> I definitely believe we should ship one ORM with Roller and the Roller
> project should not do anything to promote, document or support the
> idea of users plugging in alternative ORMs.
>
> Personally I favor JPA because 1) there will be multiple high-quality
> implementatons (some at Apache) and 2) Hibernate is one of the
> implementations. So we'd ship OpenJPA or something similar, but folks
> who *really* want to continue using Hibernate can figure out on their
> own how to configure Roller to use Hibernate's JPA implementation.
>
> On the question of "Data Mapper good or bad?"
>
> I'm +1 on Data Mapper. The Data Mapper pattern allows us to abstract
> ORM queries, just as our Persistence Strategy allows us to abstract
> ORM load/save operations. We'll have a complete persistence
> abstraction, something I've always wanted to see. The ability to
> compare JPA, JDO and possibly other ORMs seems like a key feature
> right now. Having named and externalized queries is nice too.
>
> - Dave
Re: Let's pick an implementation (was Re: New roller persistence implementation)
Posted by Dave Johnson <sn...@gmail.com>.
On 8/16/06, Anil Gangolli <an...@busybuddha.org> wrote:
> I support Elias's option #2 with some concessions to #1.
I feel about the same way.
On the question of "who here wants to replace Hibernate?"
Hibernate's LGPL licensing is incompatible with Apache policy and
there exists a set of contributors who are willing and able to provide
an alternative backend impl. I'm a member of that set. If we create an
alternative, it works well and we've got consensus then we'll ship it
with Roller. Do we have to do this before we graduate? I sure as hell
hope not.
On the question of "which ORM should we choose?"
I definitely believe we should ship one ORM with Roller and the Roller
project should not do anything to promote, document or support the
idea of users plugging in alternative ORMs.
Personally I favor JPA because 1) there will be multiple high-quality
implementatons (some at Apache) and 2) Hibernate is one of the
implementations. So we'd ship OpenJPA or something similar, but folks
who *really* want to continue using Hibernate can figure out on their
own how to configure Roller to use Hibernate's JPA implementation.
On the question of "Data Mapper good or bad?"
I'm +1 on Data Mapper. The Data Mapper pattern allows us to abstract
ORM queries, just as our Persistence Strategy allows us to abstract
ORM load/save operations. We'll have a complete persistence
abstraction, something I've always wanted to see. The ability to
compare JPA, JDO and possibly other ORMs seems like a key feature
right now. Having named and externalized queries is nice too.
- Dave
Re: Let's pick an implementation (was Re: New roller persistence implementation)
Posted by paksegu <pa...@yahoo.com>.
How about JPOX implementation of JDO?
Anil Gangolli <an...@busybuddha.org> wrote:
I support Elias's option #2 with some concessions to #1.
My strategy in similar situations would actually be to pick the
implementation and then code to its best-supported API.
Here's what I do support:
(a) Pick one and only one Apache-license-compatible ORM/persistence layer
*implementation* that we can distribute and whose use in Roller we will
support. It must be robust, reasonably efficient, and work over popular SQL
variants without us having to do a lot of our own work. (Hibernate has all
of these properties except ASF-license compatibility.)
(b) While it is definitely not a priority for me, I'm just fine with
architecting for
pluggability in order to help us switch later more easily if we need to.
However, I would only want to support the use of one API and in fact only
one implementation of that API in practice. If it happens that developers
can plug in something else at whatever level, they would be welcome to, but
they would basically be on their own. (Patches would be welcome along the
usual lines of course, but we wouldn't necessarily treat issues experienced
only on some alternate implementation as a bug.)
--a.
----- Original Message -----
From: "Elias Torres"
To:
Sent: Wednesday, August 16, 2006 5:42 AM
Subject: A forgotten option: iBatis (was Re: New roller persistence
implementation)
>
> I share some of the concerns that Jeff is bringing up in his mail and
> remember that long time ago Ted Husted had offered [1] to replace our
> Hibernate backend with iBatis or Cayenne. At the time, Dave said no
> thank you because Craig was working on JDO, but I hear mixed reviews on
> the work:
>
> 1. Some think that a pluggable strategy is good
> 2. Some would like to just pick one and move on
> 3. Some think is necessary just for license and we should always use
> hibernate
>
> We are fine with #1 and #2 not with #3. Therefore, I want to provide
> more support for #1 and #2 and suggest that if we have a pluggable
> strategy we could work on an iBatis implementation, maybe Ted will help
> us. If we choose #2, we would support an iBatis implementation. I think
> you get where I'm going. We are using iBatis internally in different
> projects and the experience has been good so far.
>
> I would love to hear your opinion on this.
>
> -Elias
Ransford Segu-Baffoe
paksegu@yahoo.com
paksegu@noqturnalmediasystems.com
http://www.noqturnalmediasystems.com/
http://www.noqturnalmediasystems.com/Serenade/
https://serenade.dev.java.net/
---------------------------------
Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2ยข/min or less.
Let's pick an implementation (was Re: New roller persistence implementation)
Posted by Anil Gangolli <an...@busybuddha.org>.
I support Elias's option #2 with some concessions to #1.
My strategy in similar situations would actually be to pick the
implementation and then code to its best-supported API.
Here's what I do support:
(a) Pick one and only one Apache-license-compatible ORM/persistence layer
*implementation* that we can distribute and whose use in Roller we will
support. It must be robust, reasonably efficient, and work over popular SQL
variants without us having to do a lot of our own work. (Hibernate has all
of these properties except ASF-license compatibility.)
(b) While it is definitely not a priority for me, I'm just fine with
architecting for
pluggability in order to help us switch later more easily if we need to.
However, I would only want to support the use of one API and in fact only
one implementation of that API in practice. If it happens that developers
can plug in something else at whatever level, they would be welcome to, but
they would basically be on their own. (Patches would be welcome along the
usual lines of course, but we wouldn't necessarily treat issues experienced
only on some alternate implementation as a bug.)
--a.
----- Original Message -----
From: "Elias Torres" <el...@torrez.us>
To: <ro...@incubator.apache.org>
Sent: Wednesday, August 16, 2006 5:42 AM
Subject: A forgotten option: iBatis (was Re: New roller persistence
implementation)
>
> I share some of the concerns that Jeff is bringing up in his mail and
> remember that long time ago Ted Husted had offered [1] to replace our
> Hibernate backend with iBatis or Cayenne. At the time, Dave said no
> thank you because Craig was working on JDO, but I hear mixed reviews on
> the work:
>
> 1. Some think that a pluggable strategy is good
> 2. Some would like to just pick one and move on
> 3. Some think is necessary just for license and we should always use
> hibernate
>
> We are fine with #1 and #2 not with #3. Therefore, I want to provide
> more support for #1 and #2 and suggest that if we have a pluggable
> strategy we could work on an iBatis implementation, maybe Ted will help
> us. If we choose #2, we would support an iBatis implementation. I think
> you get where I'm going. We are using iBatis internally in different
> projects and the experience has been good so far.
>
> I would love to hear your opinion on this.
>
> -Elias
A forgotten option: iBatis (was Re: New roller persistence implementation)
Posted by Elias Torres <el...@torrez.us>.
I share some of the concerns that Jeff is bringing up in his mail and
remember that long time ago Ted Husted had offered [1] to replace our
Hibernate backend with iBatis or Cayenne. At the time, Dave said no
thank you because Craig was working on JDO, but I hear mixed reviews on
the work:
1. Some think that a pluggable strategy is good
2. Some would like to just pick one and move on
3. Some think is necessary just for license and we should always use
hibernate
We are fine with #1 and #2 not with #3. Therefore, I want to provide
more support for #1 and #2 and suggest that if we have a pluggable
strategy we could work on an iBatis implementation, maybe Ted will help
us. If we choose #2, we would support an iBatis implementation. I think
you get where I'm going. We are using iBatis internally in different
projects and the experience has been good so far.
I would love to hear your opinion on this.
-Elias
[1] http://tinyurl.com/pjkle
Jeff Blattman wrote:
> given that JDO's future is unclear* (at best) and JPA is unproven* (are
> there any robust production tested implementations yet?), i would think
> that a "wait and see" approach would be most prudent.
>
> * = craig would know much better than i, i think
>
> i think that all things being equal it'd be better to not have the
> hibernate dependency, but it doesn't seem like now would be the right
> time to switch. if you're going to do this, make sure you won't be
> contemplating it again in 6 months.
>
> now, if folks want to put start putting things together in sandbox, by
> all means ... maybe by the time 3.x is ready, things will be clear
>
> Allen Gilliland wrote:
>>
>> So maybe it's time to ask the question more squarely ... who wants to
>> replace Hibernate as our persistence implementation?
>>
>> -- Allen
>>
>>
>>>
>>> Matt
>>>
>>>>
>>>> -- 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
>>>> > clr@apache.org http://db.apache.org/jdo
>>>> >
>>>> >
>>>>
>
Re: New roller persistence implementation (was Re: Query interface for
Datamapper)
Posted by Jeff Blattman <Je...@Sun.COM>.
given that JDO's future is unclear* (at best) and JPA is unproven* (are
there any robust production tested implementations yet?), i would think
that a "wait and see" approach would be most prudent.
* = craig would know much better than i, i think
i think that all things being equal it'd be better to not have the
hibernate dependency, but it doesn't seem like now would be the right
time to switch. if you're going to do this, make sure you won't be
contemplating it again in 6 months.
now, if folks want to put start putting things together in sandbox, by
all means ... maybe by the time 3.x is ready, things will be clear
Allen Gilliland wrote:
>
> So maybe it's time to ask the question more squarely ... who wants to
> replace Hibernate as our persistence implementation?
>
> -- Allen
>
>
>>
>> Matt
>>
>>>
>>> -- 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
>>> > clr@apache.org http://db.apache.org/jdo
>>> >
>>> >
>>>
Re: New roller persistence implementation (was Re: Query interface for
Datamapper)
Posted by Allen Gilliland <al...@sun.com>.
comments inline ...
Matt Raible wrote:
> On 8/15/06, Allen Gilliland <al...@sun.com> wrote:
>>
>> 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. 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.
>
> I don't believe that "everyone wants to do so" is an accurate
> statement. I believe "Apache wants us to do so" is an accurate
> statement. I'd rather stick with Hibernate b/c it's been proven to
> work and I know it well. Remember all the issues we used to
> experience on JRoller? I'd hate to see any of those come back again.
Actually, that's great to hear because that's exactly how I feel.
Perhaps I had misinterpreted the previous discussions about this on the
list because it had seemed like not too many ppl were voicing support
for Hibernate. For my part, I am not at all interested in replacing
Hibernate as our persistence api for the same reasons you've eluded to ...
1. Hibernate is a known quantity and many of us have some experience
with it. I don't have any experience with JDO or JPA, so switching to
either of those technologies means a new learning curve.
2. Potential risk. A lot can go wrong when you swap your persistence
layer and unless there is a burning need to do so then I think it's
worth questioning why we would want to do that. Speaking as a customer
of Roller who runs a large site, I am very nervous about the prospect of
switching the Roller persistence implementation.
3. Extra work. To replace it means a lot of extra work and for what
benefit? To get around an open source licensing issue?
So maybe it's time to ask the question more squarely ... who wants to
replace Hibernate as our persistence implementation?
-- Allen
>
> Matt
>
>>
>> -- 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
>> > clr@apache.org http://db.apache.org/jdo
>> >
>> >
>>
Re: New roller persistence implementation (was Re: Query interface for Datamapper)
Posted by Matt Raible <mr...@gmail.com>.
On 8/15/06, Allen Gilliland <al...@sun.com> wrote:
>
> 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. 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.
I don't believe that "everyone wants to do so" is an accurate
statement. I believe "Apache wants us to do so" is an accurate
statement. I'd rather stick with Hibernate b/c it's been proven to
work and I know it well. Remember all the issues we used to
experience on JRoller? I'd hate to see any of those come back again.
Matt
>
> -- 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
> > clr@apache.org http://db.apache.org/jdo
> >
> >
>
Re: New roller persistence implementation (was Re: Query interface
for Datamapper)
Posted by Craig L Russell <Cr...@Sun.COM>.
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
>> clr@apache.org http://db.apache.org/jdo
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
New roller persistence implementation (was Re: Query interface for
Datamapper)
Posted by Allen Gilliland <al...@sun.com>.
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.
that's not really useful to people who are running roller and it's more
overhead to maintain for us roller developers.
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. 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.
-- 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
> clr@apache.org http://db.apache.org/jdo
>
>