Bill,
It looks like you didn't send this to the list, only to me.
I wanted to clarify a couple of things, especially where you thought that my
approach would require extensive metadata mods. My intention is that the only
addition would be the <query> element, which has a 'class' attribute and then
the existing custom <attribute> tag. Knowledge of hard coded values,
child/parent references, AND/OR, etc. would be in the concrete Builder
implementation class itself - Java is a much better language than XML to express
this kind of stuff.
So, looking at my example, the BuildProjectsQuery would know its job is to add a
couple of criteria to handle the requested date range. The Builder would in
this case be specific to a particular relationship. A given Builder
implementation would document the specific attribute names (which really are
parameters, as you wrote) which it expected to find in its CollectionDescriptor.
As far as being overkill for a simple restriction, I was thinking that OJB would
eventually ship with a number of basic Builders - NonFKCollectionQueryBuilder,
ConstantFieldQueryBuilder, DateRangeQueryBuilder, etc. That way we get the best
of both worlds - simple end-user specification of simple restrictions, and lots
of flexibility for those who need it.
-steve
>Date: Fri, 21 Feb 2003 10:13:30 -0800 (GMT-08:00)
>From: V B Skrypnyk <[EMAIL PROTECTED]>
>To: sclark <[EMAIL PROTECTED]>
>Subject: Re: 1:M querys constraints
>
>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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
