db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Clute, Andrew" <Andrew.Cl...@osn.state.oh.us>
Subject RE: Any plans for Reference filters?
Date Thu, 23 Sep 2004 19:58:48 GMT
Yeah, after looking at some of the code, it only gets a chance to do
that after the parent object has been determined, and then wants to get
the collection. It will filter it then.

However, the more useful case, is that it does not allow for the query
to customize for the initial query. So, if your 'filtered' collection is
part of a join path, the extra criteria is not added.

For example, if I have a collection on person called fileteredAddresses,
doing

Sc.addEqualTo("person.filteredAddresses.city","New York") 

will not allow the QC to change the query for the initial search for
people. So, if I wanted to find all the people whose filtered addresses
had a city of New York, it currently will return me persons that have
*any* address that has the city of "New York", and *then* filter out the
addresses on that person. That works great, except if the person has no
filtered addresses that meets that criteria, he should never have been
returned in the first place.

Make sense?

-Andrew

 

-----Original Message-----
From: Jakob Braeuchi [mailto:jbraeuchi@gmx.ch] 
Sent: Thursday, September 23, 2004 3:21 PM
To: OJB Developers List
Subject: Re: Any plans for Reference filters?

hi andrew,

the query customizer gets the parent object and the query (by criteria),
so it's up to the customizer to modify the query. the query is processed
as any other query.

jakob

Clute, Andrew schrieb:

> Yeah, looking at the code that is used for the query customizer on 
> Collections, I would assume it would be real straight forward to add 
> that to references as well.
> 
> Now a quick question about how QC's work.
> 
> Assume my scenario of Person with addresses collection, and the need 
> for a 'filtered' Primary Address, property named 'primaryAddress'. If 
> I did something like this:
> 
> Sc.addEqualTo("person.primaryAddress.zipcode","90210");
> 
> Would it be smart enough to allow the customizer to add it's 
> filtereing on the JOIN query? Does it work that way for Collections
right now?
> 
> 
> 
> -----Original Message-----
> From: Jakob Braeuchi [mailto:jbraeuchi@gmx.ch]
> Sent: Thursday, September 23, 2004 2:59 PM
> To: OJB Developers List
> Subject: Re: Any plans for Reference filters?
> 
> hi andrew,
> 
> got me ! you're right query customizer only works for collections but 
> imo it should be possible for references as well. so we could have a 
> single concept for filtering.
> 
> jakob
> 
> Clute, Andrew schrieb:
> 
> 
>>Can you put a query customizer on a reference descriptor? I thought 
>>they were only for collections!
>>
>>-Andrew
>>
>> 
>>
>>-----Original Message-----
>>From: Jakob Braeuchi [mailto:jbraeuchi@gmx.ch]
>>Sent: Thursday, September 23, 2004 12:59 PM
>>To: OJB Developers List
>>Subject: Re: Any plans for Reference filters?
>>
>>hi andrew,
>>
>>you could use a query customizer to manipulate reference queries. i 
>>admit it's not as elegant as the filter but it's totally flexibel ;)
>>
>>jakob
>>
>>Clute, Andrew schrieb:
>>
>>
>>>I have run into a couple of scenarios where it would be extremely 
>>>helpful to be able to add additional criteria to a reference
>>
>>descriptor.
>>
>>
>>>For instance, you might have a Person object with a collection of 
>>>Addresses on them. Address might have a property called "Primary". In

>>>your query, you might want to be able to qualify to use the primary 
>>>address. The current way to do that is to keep a foreign key on your 
>>>person table that links back to the primacy address object, and 
>>>update
>>
>>
>>>that when your primacy address changes. So, you have both a property 
>>>on your object, and a db column.
>>>
>>>It would be nice if you could still have that reference descriptor 
>>>for
>>
>>
>>>your person object for a Primary Address, but not maintain the 
>>>foreign
>>
>>
>>>key in the db, just had a certain criteria to the descriptor that 
>>>filters it to the appropriate one.
>>>
>>>For instance:
>>>
>>><reference-descriptor
>>>	name="primaryAddress"
>>>	class-ref="pojo.Address"
>>>	refresh="true"
>>>	auto-retrieve="true"
>>>	auto-update="false"
>>>	auto-delete="false"
>>>
>>>	<foreignkey field-ref="personPK"/>
>>>	<foreignkey-filter value="is_primary=1"/>
>>
>></reference-descriptor>
>>
>>>Does that make sense? Just curious if this has ever been discussed.
>>>
>>>Thanks!
>>>
>>>-Andrew
>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org For 
>>>additional commands, e-mail: ojb-dev-help@db.apache.org
>>>
>>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org For 
>>additional commands, e-mail: ojb-dev-help@db.apache.org
>>
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org For 
>>additional commands, e-mail: ojb-dev-help@db.apache.org
>>
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org For 
> additional commands, e-mail: ojb-dev-help@db.apache.org
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org For 
> additional commands, e-mail: ojb-dev-help@db.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org For additional
commands, e-mail: ojb-dev-help@db.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Mime
View raw message