Hi,
I would agree with Steve's approach. I think it would require fairly
extensive configuration addition to metadata to support all
possible types of restrictions, as they can reference hard coded
values, as well as references to child and/or parent fields
(with appended hard coded tokens like '%' for like restrictions),
as well as AND / OR, etc.
On the other hand, having a wholly custom query defined for
a collection may be an overkill for a simple restriction. Perhaps,
it may simplify matters, if there is a provision for a callback class
that would modify a naturally existing association, like so:
<collection-descriptor
name="projects"
elementClass="gov.doi.cap.ojb.dataobjects.Project"
..>
<constraint class="my.custom.query.restrictor">
<parameter key="key1" value="value1"/>
<parameter key="key2" value="value2"/>
</constraint>
</collection-descriptor>
The query restrictor would get an access to the already existing
Query and can add or remove terms from it.
In any case, there is still an issue of how to pass dynamic
parameters for query restriction at runtime. Any other options besides metadata
manipulation?
It would be nice to do something like this:
Engineer e = < get engineer from data store >
e.setProjectCollectionConstraints( firstDate, secondDate );
Iterator it = e.getProjects();
while( it.hasNext() ) {
...
}
In this case the restrictor callback or query builder would have
to have an access to the instance of the object that 'originates'
the query. Any ideas?
--Bill.
>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]
