Re[4]: anonymous fields

[Alexander Prozor <ap...@isd.dp.ua>]

Hello Brian,
thank you, but I don't receive any attachments :(.
and in cvs I sow old xml file :(.
but that's all bad news :))))

the good news that all works now, after moving reference-descriptor to
another class ( and adding additional parameter to that class, 'cause
OJB didn't see anonymous field in this case - and I don't have time
enough to correct this error :) ).

so - thank you very much.


To:Raymond Barlow <rb...@raymanoz.com>

Thank you too :) you were right from very begin :))))

BM> I just put the working code into the howto and sent the patch to the
BM> developer list, but I figured you might want to correct docs asap - so 
BM> they are attached.

BM> The only real difference (aside from two typos) was the 
BM> reference-descriptor being in the wrong class def (desk references 
BM> finish, not finish references desk as it is in cvs right now - that 
BM> would be a 1:M style).

BM> -Brian




-- 
Best regards,
 Alexander                            mailto:apro@isd.dp.ua

Re[3]: anonymous fields

[Alexander Prozor <ap...@isd.dp.ua>]

ohhh,
now it's work again :)
actually I don't understand how it work for now :))))).
another question,
does anybody stored HashMap member?


-- 
Best regards,
 Alexander                            mailto:apro@isd.dp.ua

Re: Re[2]: anonymous fields

[Brian McCallister <mc...@forthillcompany.com>]

> Hi again,
> actually I was too optimistic,
> it's work without exception , but only for my test ( when I store
> object and then get it by query ).
> when I trying to get previously stored object I got null as value of
> referenced member :(.
>

One thing to be careful of when you see behavior like this is the 
caching mechanism. By default OJB does not update cascade/delete 
cascade. This is important because the reference for a collection is 
stored in the database on the object IN the collection, instead of in 
the collection. As long as the PB is retrieving from a cache the 
Collection instance belonging to the cached object will be used, but 
once it leaves the cache, boom. I haven't had a chance to really 
explore the exact behaviors, but I have seen grief and woe from it 
myself.

When using the PB API (the only one I have really used) I tend to go 
ahead and set up cascades for dependent objects (wholly dependent 
entities anyway).

Anyway, one thing I have found helps to find these for me early is to 
always flush the cache after writes in my unit tests. In theory you 
could change to an empty cache implementation for testing, but flushing 
the cache at the end of setUp() is easy and more accurate for what you 
want in most cases.

-Brian

Re[2]: anonymous fields

[Alexander Prozor <ap...@isd.dp.ua>]

Hi again,
actually I was too optimistic,
it's work without exception , but only for my test ( when I store
object and then get it by query ).
when I trying to get previously stored object I got null as value of
referenced member :(.
controlRoorRef.
maybe I have to store this reference descriptor in the 'Table' ?

-- 
Best regards,
 Alexander                            mailto:apro@isd.dp.ua

Re: anonymous fields

[Raymond Barlow <rb...@raymanoz.com>]

Hi Guys,

*Phew*, I'm happy to see that I wasn't miles off target!

Keep up the good work people!

Cheers,
Raymond Barlow

Alexander Prozor wrote:

>Hello Brian,
>thank you, but I don't receive any attachments :(.
>and in cvs I sow old xml file :(.
>but that's all bad news :))))
>
>the good news that all works now, after moving reference-descriptor to
>another class ( and adding additional parameter to that class, 'cause
>OJB didn't see anonymous field in this case - and I don't have time
>enough to correct this error :) ).
>
>so - thank you very much.
>
>
>To:Raymond Barlow <rb...@raymanoz.com>
>
>Thank you too :) you were right from very begin :))))
>
>BM> I just put the working code into the howto and sent the patch to the
>BM> developer list, but I figured you might want to correct docs asap - so 
>BM> they are attached.
>
>BM> The only real difference (aside from two typos) was the 
>BM> reference-descriptor being in the wrong class def (desk references 
>BM> finish, not finish references desk as it is in cvs right now - that 
>BM> would be a 1:M style).
>
>BM> -Brian
>
>
>  
>