Re: How to check for null values when using proxies?

Armin Waibel <[email protected]> Sat, 16 Feb 2008 01:59:57 +0100
Newsgroups gmane.comp.jakarta.ojb.user
Message-ID <[email protected]>
Hi,

Schmidt wrote:
> Hi Armin,
> 
> Thank you for the answer.
> 
> I'm using the 1.0.4 version. And the same problem happens with 1:n
> associations as well.

If you use lazy loading with 1:n or m:n relation OJB always create a 
collection proxy object (this helps to avoid a DB query on object 
materialization). Recommended way to check n-side existence is to use 
Collection.size() method. In this case OJB performs a count-query to 
verify the number of the n-side objects.


> In the 1:n associations I set auto-retrieve="false"
> and proxy="dynamic". As my classes do not implement interfaces, I'm using
> CGLib as ProxyFactoryClass.

The setting proxy="dynamic" is an illegal attribute value for reference- 
and collection-descriptors (only true/false is valid). It doesn't make 
sense (please correct me if am wrong) to use auto-retrieve="false" 
(prevent materialization of the 1:n or m:n relation)
http://db.apache.org/ojb/docu/guides/basic-technique.html#Setting+Load%2C+Update%2C+and+Delete+Cascading
in combination with proxy="true" (lazy-loading).

> I debugged the source code and verified that the collection representing the
> n side of the 1:n association is filled with proxy references. That's good
> because the real object are not materialized, but when I check for nullity,
> the result is false due to proxy references. The solution (ugly) to bypass
> this problem is in the ProxyHelper.getRealObject method. But this solution
> is invasive, proxies should be transparent.

Please use Collection.size()

> 
> Another problem that came up after I started using proxies is in the
> hierarchy mapping. I'm using just one table to map my class hierarchy. So,
> this table has a CLASSNAME field to identify which class to load. In the
> constructor of my base class I have a
> setOjbConcreteClass(this.getClass().getName()) call. Before using proxies,
> the class name was configured correctly. But after, instead of having the
> real object class name, the application configures the classname field using
> the proxy class name.
> 
> I assume there should be something wrong with my mapping files or some other
> point in my application. As said earlier, I believe proxies should be
> transparent. Did someone here experience the same problems?

Hm, I will have a look at this tomorrow (will try to reproduce your issue).

regards,
Armin

> 
> Thank you again!
> 
> 
> Armin Waibel wrote:
>> Hi,
>>
>> Schmidt wrote:
>>> Hi,
>>>
>>> Consider that an object A has an association with an object B. Also that
>>> dynamic proxies are in use so that when object A is loaded, a proxy to B
>>> is
>>> created and the object B itself is not materialized. Sometimes, before
>>> taking an action, I need to verify if there is a B object associated to
>>> A.
>>> This check is done as follows:
>>> if (a.getB() == null) {...}
>>>
>>> The problem is that even if there isn't a B associated with A, OJB
>>> returns
>>> false because there is always a proxy between A and B. The check is
>>> actually
>>> done using the proxy reference which is always present.
>>> How can we handle that?
>>>
>> Which version of OJB do you use? I try to reproduce this with the 
>> current source (OJB_1_0_RELEASE branch) without success. If class 
>> Article has a 1:1 relation to ProductGroup and I search for an Article 
>> without a ProductGroup I get:
>>
>> Criteria c = new Criteria().addEqualTo("articleName", name + "without
>> PG");
>> q = QueryFactory.newQuery(ArticleWithReferenceProxy.class, c);
>> Article br = (ArticleWithReferenceProxy) broker.getObjectByQuery(q);
>> assertNotNull(br);
>> assertNull(br.getProductGroup());
>>
>> Could it be that the association between A and B is a 1:n relation?
>>
>> regards,
>> Armin
>>
>>> Thank in advance!
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>>
>