Re: 1:M querys constraints

Jakob Braeuchi Fri, 21 Feb 2003 11:52:11 -0800

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]

Re: 1:M querys constraints

Reply via email to