Hi Jacob,
This seems to me to be an optimal solution. If I have the originator object,
dynamic parameters are not an issue.
--Bill.
----- Original Message -----
From: "Jakob Braeuchi" <[EMAIL PROTECTED]>
To: "OJB Users List" <[EMAIL PROTECTED]>
Sent: Friday, February 21, 2003 11:49 AM
Subject: Re: 1:M querys constraints
> hi bill,
>
> imo steve's proposal provides a lot more flexibility than mine. the
> query restrictor will only modify the foreignKeyQuery it will not build
> the whole query. so it needs the originator object and the
> foreignKeyQuery based on the collection-descriptor, and what it does
> with this query is up to the restrictor. i do not see a need for dynamic
> metadata modifications so far.
>
> jakob
>
> V.B. Skrypnyk wrote:
>
> >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]
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> 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]
