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
[EMAIL PROTECTED] http://db.apache.org/jdo
