what i miss in this approach is the operation (=, <>, like, between etc.) .
as far as i understand your proposal, the operation and the whole logic is dependent of the query-builder. this makes it quite easy for us to implement it in ojb, but it moves the burden of implementation to the user. especially when you think of accessing the 'originator' object as bill pointed out.
as there are lots of possibilities for query-constraints, i'm not sure whether we'll be able to provide the most useful ones (from a user's point of view). on the other hand your approach provides all the flexibility one might need...
imo we should just provide a standard query-restrictor using static parameters and operations for those who need simple restrictions only.
just my 0.02 chf
jakob
sclark wrote:
Here's an idea on the collection restriction discussion. How about something like this:
/**
* Interface implemented by classes which are used to create a custom
* query for the contents of a collection property, when the usual
* fk/pk approach is insufficient.
*/
interface org.apache.ojb.broker.query.QueryBuilder /** Build the query to retrieve the specified collection property */
Query buildQuery(Object obj, ClassDescriptor cld, CollectionDescriptor cds);
}
class PersistenceBrokerImpl { private void retrieveCollection(...) { if (cds.getQueryBuilder() != null) { fkQuery = cds.getQueryBuilder.buildQuery(obj, cld, cls); } else if (cds.isMtoNRelation()) { fkQuery = getMtoNQuery(obj, cld, cds); } else { fkQuery = getForeignKeyQuery(obj, cld, cds); } } }
Then in my app I would write something like this:
class gov.doi.cap.ojb.query.BuildProjectsQuery implements QueryBuilder { ... }
<collection-descriptor
name="projects"
elementClass="gov.doi.cap.ojb.dataobjects.Project"
... >
<query class="gov.doi.cap.ojb.query.BuildProjectsQuery">
<attribute attribute-name="earliestStart"
attribute-value="1999"
/>
<attribute attribute-name="latestStart"
attribute-value="2001"
/>
</query>
</collection-descriptor>
This would allow great flexibility in the specification of the collection contents, without requiring a query syntax to be defined in XML.
-steve
Steve Clark Technology Applications Team Natural Resources Research Center/USGS [EMAIL PROTECTED] (970)226-9291
Date: Fri, 21 Feb 2003 17:49:32 +0100 From: Jakob Braeuchi <[EMAIL PROTECTED]> To: OJB Users List <[EMAIL PROTECTED]> Subject: Re: 1:M querys constraints
hi bill,
what kind of restrictions woukd you need in the collection-descriptor ? do we need the full blown criteria there ? have you already any ideas about the definition of these restrictions ?
i'm asking these questions because i do not want to parse restrictions in the collection-descriptor.
i prefer a simpler solution like :
<restriction field="firstname" operation="=" value="Mark" /> <restriction field="lastname" operation="like" value="M%" />
how could we handle 'AND' / 'OR' ?
what do yout think about ?
jakob
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
