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