incubator-isis-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Meyer - KMZ" <ke...@kmz.co.za>
Subject Re: Infinite recursion with JDBC SQL Object store
Date Thu, 01 Sep 2011 18:10:38 GMT
Hi Barry,

> Thank you both for your prompt replies and apologies for my late response
> but I have been dragged on to other work the last several days.

Great that you came back, though. I've had a rough week myself - and 
have not had a chance to look into this. Things are looking better next 
week, though...

 
> Since sending my original email I have had a closer look in an effort to
> better understand the JDBC object store codebase. It occurs to me that a
> possible fix is for changes to the AbtractAutoMapper.setupFullMapping method
> to ignore further mapping of any association fields of the same type as the
> class being mapped. This would fix the recursion issue but I am unsure
> whether that would have any undesirable side effects.

Thanks - I'll see how this can be done. I'll also try and add some tests 
to examine this behaviour.

> > My immediate suggestion is to consider a bit of jiggery: can you make your
> class implement an (empty) interface, and > have your collection be a
> collection of the interface instead of the full class? This ought to prevent
> the infinite > > recursion, but I'm not sure what else it'll break.
> 
> Kevin, unfortunately your suggestion won't work because the JDBC persistor
> doesn't support polymorphism. This is a fundamental problem for us as our
> domain model depends heavily on polymorphic associations.

I can't remember testing this - you may be right.

The one behaviour I *have* noticed is that the SQL-OS does not 
correctly return all instances of sub-classes. Consider:

class BaseClass {
}

class SubOne extends BaseClass {
}

class SubTwo extends BaseClass {
}

then the Factory/Repository method:
allInstances(BaseClass.class) does not return instances of SubOne 
and SubTwo - you'd have to manually fetch instances of them and add 
them to the list.

I seem to recall that the XML Persistor worked as expected.

> In order for dynamic extensions to work it is essential that the LinkObject
> defines the from/to node associations as the shared supertype i.e. as Node
> because any node can have a relationship to any other node (subject to some
> business rules). This strategy works fine for the XML persistor but falls
> down with the JDBC persistor.

Is this related to what I just listed, above?

> Examination of this problem shows that when nodes are added to the graph
> everything works nicely during the same persistence session. The problem
> arises when a new persistence session is started (e.g. when starting the
> application again) and the framework commences re-instantiation and
> rehydration of the persisted objects. There is no information in the
> persisted LinkObject rows about the original subtypes and so it attempts to
> re-instantiate the objects as supertype instances which eventually falls
> over. Presumably the XML persistor works because the stored association
> fields are type agnostic.

Again, I need to write some test code to demonstrate this behaviour.

If I can repeat: you're saying that, using my example classes above, if:

class Node {
	List<BaseClass> baseClasses(){}
}

then the baseClasses collection is not correctly restored with instances 
of SubOne and SubTwo, as expected?

> It occurred to me that I could use the JDO strategy for dealing with
> polymorphism which is to store the persisted primary key as a primitive
> value rather than as a reference in the LinkObject association. We could
> also store a fully qualified class name for the from/to associations
> providing all the information required for re-instantiation. This of course
> presents some difficulties with ISIS because the OID is not accessible from
> the applib. Presumably even if the OID was available, to make this useful we
> would also need an additional query method to query by OID value. 

To support this, your domain repository interface should include 
methods of the form:

interface NodeFactory {
	Oid oidFor(Node node);
	Node nodeFor(Oid oid);
} 

then we just need to interact with the actual persistor to map between 
the (SqlOid or SerialOid? What does the XML Persistor use?) and the 
object.

Dan? What's your feeling / input here?

 
> I would be very interested in your views on the suggestion above and any
> other strategies you might suggest for overcoming theses issues. 

How does Hibernate handle your situation?   

> Regards,
> 
> Barry
> 

Regards,
Kevin


Mime
View raw message