Thanks Jakob,
I am going to have a look at this later this week.
(What a great turn-around time! :)
--Bill.
----- Original Message -----
From: "Jakob Braeuchi" <[EMAIL PROTECTED]>
To: "OJB Users List" <[EMAIL PROTECTED]>
Sent: Wednesday, February 26, 2003 11:56 AM
Subject: Re: 1:M querys constraints
> hi all,
>
> i just added some fixes to support customizable 1:n queries.
> just add a query-customizer class to the collection-descriptor.
> this class must implement the QueryCustomizer interface, a
> QueryCustomizerDefaultImpl is alreay there as a base class.
>
> ....
> <query-customizer
>
> class="org.apache.ojb.broker.accesslayer.QueryCustomizerDefaultImpl">
> <attribute
> attribute-name="attr1"
> attribute-value="value1"
> />
> ....
>
> the interface defines the single method below which is used to customize
> (or completely rebuild) the query passed as argument. the interpretation
> of attribute-name ans attribute-value is up to your class !
>
> /**
> * Return a new Query based on the original Query, the originator
> object and
> * the additional Attributes
> *
> * @param anObject the originator object
> * @param aBroker the PersistenceBroker
> * @param aCod the CollectionDescriptor
> * @param aQuery the original 1:n-Query
> * @return Query the customized 1:n-Query
> */
> public Query customizeQuery(Object anObject, PersistenceBroker
> aBroker, CollectionDescriptor aCod, Query aQuery);
>
> hth
> jakob
>
>
> sclark wrote:
>
> >Jakob,
> >
> >You are correct; all of the logic is in the Builder class. As you say,
> >there are lots of possibilities for these constraints. I think that the
> >best way to express them is to use Java, rather than trying to invent
some
> >new syntax that fits inside of XML. And I bet that a fairly small set of
> >stock builders, appropriately parameterized, would hit the vast majority
> >of cases.
> >
> >Hmmm ... I bet it would be quite easy to write an OqlQueryBuilder
> >which would take a single parameter, an OQL string, and parse it.
> >Imagine this:
> >
> ><class-descriptor class="Employee" ...
> > <collection-descriptor
> > name="recentOutsideProjects"
> > elementClass="Project"
> > ... >
> > <inverse-foreignkey field-ref="employeeId" />
> > <query class="OqlQueryBuilder">
> > <attribute
> > attribute-name="queryString"
> > attribute-value="project.startDate.year > 2000 and project.org <>
emp.org"
> > />
> > </query>
> > </collection-descriptor>
> >
> >Heck, maybe we could even write:
> >
> > <collection-descriptor
> > name="recentOutsideProjects"
> > elementClass="Project"
> > ... >
> > <inverse-foreignkey field-ref="employeeId" />
> > <query language="oql"
> > queryString="project.startDate.year > 2000 and project.org <>
emp.org"
> > />
> > </collection-descriptor>
> >
> >One of the reasons that I prefer a Builder to a Refiner is that I have
> >relationships which don't involve FK's at all, so I'd like a way to
> >express those and never get any of the default Criteria in there. But
> >maybe it's sufficient to use a refinement approach, and make the FX spec
> >optional in repository.xml if there's a query. That way if I have FK's,
> >I can refine; if there aren't FK's, then I can just start from scratch.
> >
> >-steve
> >
> >
> >
> >
> >>From: Jakob Braeuchi <[EMAIL PROTECTED]>
> >>
> >>hi steve,
> >>
> >>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]
> >>
> >>
> >>
> >
> >
> >---------------------------------------------------------------------
> >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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
