Exactly and this is one reason why delegating the work to OJB for queries. This * must* not be bad design at all.I completely agree with it being bad design. However, I am using OJB in struts applications. Lets take the example i gave before. The struts action would simply load a collection of managers from OJB, and put them into the request scope. The action would forward to a JSP. The JSP would itterate through the Managers, and the Employees within them, and print them to the screen. This is done using Tag libraries.
If the Managers datd only has Employees that match the (dynamicly generated) query specifications, all the JSP has to do is itterate through the data.
If the Managers data has Employees that dont match the query specifications, then the query has to be handled at the JSP level, which definitely is bad design! Also this creates a problem that web designers can cope with taglibs, but cannot cope with writing scriptlets.
One solution is to create pageview that mimic data objects (and can even reuse the same beans) but are copies of the contents. Thus you copy the managers details into a pageview object, and copy only the employees you want into the pageview manager objects. However this means more code.
It depends on the application I think.
Another point is that I have a aditional hand written subselect which must be maintained and I can not see
this problem by looking at the deployment descriptor. By using a queryCustomizer you can see at the
descriptor that there is a dependency and where to make modifications if neccessary.
best regards,
Guido
Another downside of this solution is the performace loss of materialising lots of objects that are unwanted.
Would the following query (slightly changed from your query) have any implications on caching, etc? Would the cache not realise that criteria have been used?
Criteria crit = new Criteria(); crit.addEqualTo("fooKey", fooKey); crit.addEqualTo("bar.barKey", barKey); Query q = QueryFactory.newQuery(Foo.class, crit); Collection results = broker.getCollectionByQuery(q);
Daniel.
----- Original Message ----- From: "Lance Eason" <[EMAIL PROTECTED]>
To: "OJB Users List" <[EMAIL PROTECTED]>
Sent: Friday, December 19, 2003 4:49 PM
Subject: RE: How to pass dynamic attribute values to QueryCustomizer
Implementations
It's entirely possible to do this, but in general I think it's a bad design *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.
--------------------------------------------------------------------- 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]
