Hi Peter,
Peter Wieland wrote:
Hi Brian and the rest,
Just started trying to make a patch but as you said, this will "break things left and right". I think the difficulty is not to fix the problem itself but to understand which places are affected by the changes. I could go on trying to get it working but I'm afraid I would have to touch quite a lot of files as this is very deep in the OJB codebase. Hence there are a lot of decisions to make and I'm not sure whether I am the right one to do so.
I'm just a bit afraid of changing things deep in the OJB core as I am not very familiar with your code.
What do you think could be a good way to collaborate?
As Brian mentioned it will be a huge change in kernel classes to make OJB work with multiple extents for one class. On the other side Thomas D. think about changes in metadata to avoid the "extent" declaration, so I think we should discuss this on dev-list.
regards, Armin
Peter
-----Urspr�ngliche Nachricht-----
Von: Brian McCallister [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 8. Juli 2004 12:45
An: OJB Users List
Betreff: Re: AW: Cache and Inheritance
Good find.
Easiest way to get it fixed is to submit a patch ;-)
Otherwise opening a bug in the bug tracker is good, and pinging us on -dev periodically if it doesn't seem anyone is acting on it. That said, this is pretty significant -- it also makes the cd.getTopLevelClass(..) call pretty tricky as it should be capable of returning a tuple now, butthat will break things left and right =/
-Brian
On Jul 8, 2004, at 7:35 AM, Peter Wieland wrote:
Hi again,
I digged a little deeper. The problem occurs in fact, when a class is
in
more than one extent. In my example, Product implements two interfaces
TextLinkable and ImageLinkable. I'm afraid this scenario was not one, OJB
developers thougt about.
In DescriptorRepository.addExtent(String classname, ClassDescriptor
cld),
mappings between extents and the class descriptors of their superclasses are
stored. If interfaces come into play - i.e. one class may belong to more
than one extent - the last extent added wins as each extent/superclass
mapping uses the extent class name as unique key and thus previously
registered mappings are simply overwritten.
In my example, getBroker().getTopLevelClass(Product.class) returns ImageLinkable.class. Hence, it is not found in the cache when looking for it as a TextLinkable (Identity.equals() compares toplevel classes and OIDs).
Is there an easy way to get this fixed?
Regards,
Peter
PS: While writing this mail, I felt like this belongs more to the
developer
list. Maybe we can continue discussion there. I sent a copy to both lists.
-----Urspr�ngliche Nachricht----- Von: Peter Wieland [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 8. Juli 2004 10:48 An: [EMAIL PROTECTED] Betreff: Cache and Inheritance
Hi all,
I just wrote the following mail to the user list. Here it is a second
more
time for two reasons:
1) I used a mail account not subscribed to the list, hence I do not know
whether it will be accepted.
2) I just updated my App for use with OJB 1.0. The problem did not change.
So forget about my last question whether the problem is fixed or not in 1.0.
It is NOT.
Peter
===
Hi all,
I have the following scenario:
<<interface>> TextLinkable (0..*)---(0..1) TextModule
And a class Product implementing TextLinkable (Product is declared as extent of TextLinkable in repository).
It now appears that I have different instances of the same Product in
my App
which is not what I expect. Normally the use of a cache makes sure that
persistent identity is equivalent to java identity (which works fine in most
cases). I suppose that the cache does not correctly resolve identities when
inheritance comes in to play.
The TextModule class holds a dynamic proxy for the associated
TextLinkable.
Is it possible, that, when materializing this proxy, it does not find an
existing Product (which would be the real object in this case) in the cache,
because the cache is searched for classes of runtime type TextLinkable
(there are none, as TextLinkable is an interface)?
I observed the problem with OJB RC5. Is this a known problem? Anybody knows whether it is fixed in 1.0?
Thanks for any help.
Peter
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
