Hi Steve,
> It looks like you didn't send this to the list, only to me.
Sorry, email client woes :((
> 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.
I was referring to Jacob's suggestion -- yours doesn't require any major
metadata
extensions.
> 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.
Still, how would you address dynamic parameters to your restricted queries.
Your date range is a perfect example. I imagine you may want to change this
range at runtime. Would you have to modify the metadata at runtime as well.
Doing it this way seems a little scary, because you are then responsible for
restoring the previous state if you don't want the changes to persist (even
in the same thread).
> 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.
The reason why I suggested to do a callback was because from the user
perspective I am ignorant of the way that the association between the
objects is constructed -- I am only interested in restricting that
association. So if a collection descriptor specifies an M:N relationship or
1:N relationship I felt it would be a duplication of an already existing
mechanism to replicate logic how to construct these queries in a custom
query builder, if I only need to restrict it. Perhaps, one may argue that
you also have to know enough about the query to be able to modify it in the
callback...
Regards,
--Bill
> -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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
