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.
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]
