Re: How to pass dynamic attribute values to QueryCustomizer Implementations

[Guido Beutler]

Hi,

Lance Eason wrote:

It's entirely possible to do this, but in general I think it's a bad design *to* do it.  

I never said that it is the best way to do it. :-)

Collection descriptors are used to model relationships, not arbitrary dynamic queries.  The role of query customizers is to allow you to statically refine the relationship to make it more specific than just foreign-key/primary-key.  What you're attempting to do is to abuse the mechanism to make it a dynamic query mechanism which isn't the intention.  As a result I think you'll find a lot of subtle problems pop up if you go down this route, the first being caching (e.g. what happens when the parent item you're retrieving is answered from the cache and already has a collection that was customized dynamically from the last time it was used).  What I really think you want to do here is expose you're dynamic queries off of accessors you write yourself rather than trying to wedge them into collection descriptors.  Something like:

<class-descriptor class="Foo" table="Foo">
  <field-descriptor id="1"
     name="fooKey"
     column="foo_key"
     jdbc-type="INTEGER"
  />
</class-descriptor>
<class-descriptor class="Bar" table="Bar">
  <field-descriptor id="1"
     name="barKey"
     column="bar_key"
     jdbc-type="INTEGER"
     primarykey="true"
     autoincrement="false"
  />
  <field-descriptor id="2"
     name="fooKey"
     column="foo_key"
     jdbc-type="INTEGER"
     primarykey="true"
     autoincrement="false"
  />
</class-descriptor>
public class A
{
  private Integer fooKey;
  public Collection getBarsByKey(int barKey)
  {
     Criteria crit = new Criteria();
     crit.addEqualTo("fooKey", fooKey);
     crit.addEqualTo("barKey", barKey);
     Query q = QueryFactory.newQuery(Bar.class, crit);
     Collection results = broker.getCollectionByQuery(q);
  }
}
As an added bonus you don't have to play any tricks to get your dynamic information down to a query customizer, the dynamic information simply comes in as attributes on the method invocation.

If you insist on doing it the other way, the traditional way to pass arguments past an interface that doesn't support it is to use ThreadLocal but I really think you would be better served by reconsidering your design.

 

You're right, that your solution would work. The other point of view ist 
that you have to write aditional code, the getBarsByKey method.
Of course this is more flexible than using a fixed class. Maybe 
dependent of the application which way is the better one.
I'll check what your solution would mean for my application.

Thanks, it's really another point of view.

best regards,

Guido



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]