incubator-isis-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Barry Woods" <barry_wo...@bigpond.com>
Subject RE: Infinite recursion with JDBC SQL Object store
Date Thu, 01 Sep 2011 03:07:00 GMT
Hi Dan & Kevin,

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.

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.

I will raise a JIRA for this issue later today and attach the log extract. 

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

Our domain models a directed graph of nodes and the relations between them.
We have a base class named (not surprisingly!) Node. These nodes can be
represented by one of several built-in subtypes, but in addition the model
supports dynamic extension allowing for new node types and hence subclasses
to be added. The relationships between nodes are represented by LinkObject
instances.

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.

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.

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. 

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

>> using ISIS to develop a major application and we have been using the 
>> XML persistor for most development undertaken to date. This project 
>> includes the development of a custom ISIS viewer based on GWT for a 
>> specialized UI that is now in beta.

> That's a pretty major undertaking; it'd be nice to hear more about this.

Dan, the custom UI presents tailored views for each of the nodes according
to type. In addition it will allow us to view the graph as a graph and to
zoom in to different parts of the graph to see immediate relations. Clicking
on a node displayed in the graph will open the tailored view. If you
interested I will provide more details as the design of this part of the
viewer is bedded down.

Regards,

Barry

-----Original Message-----
From: Dan Haywood [mailto:dkhaywood@gmail.com] On Behalf Of Dan Haywood
Sent: Friday, 26 August 2011 4:45 AM
To: isis-dev@incubator.apache.org
Subject: Re: Infinite recursion with JDBC SQL Object store

On 24/08/2011 17:15, Barry Woods wrote:
> Hi Dan,
> Have been following the evolution of NO into ISIS with interest.
Good to hear!


We are
> using ISIS to develop a major application and we have been using the 
> XML persistor for most development undertaken to date. This project 
> includes the development of a custom ISIS viewer based on GWT for a 
> specialized UI that is now in beta.

That's a pretty major undertaking; it'd be nice to hear more about this.


> We recently initiated a move to the SQL object store so we can get 
> multi-user operating...I really don't understand this part of the 
> framework sufficiently to debug this. Any pointers or assistance you 
> can provide would be greatly appreciated.

I'm afraid I can't help you much, at least insofar as Rob wrote this code
originally and I've not had the need to look into it.  I see from Kevin's
reply that he's going to see if he can assist.  If he gets nowhere then I'll
see what I can do.

The other thing that I am happy to do - which might be another way forward
for you - is to resurrect the JPA object store that I wrote against NOF.
This isn't part of Isis because it uses Hibernate, which is LGPL (not
compatible with ASF policy).  However, on my todo list is to update the code
as it currently is and to check into apache-extras.org [1] (a subsequent
todo is to port it from Hibernate to OpenJPA so it can become part of Isis
proper).  At any rate, there's coverage of the JPA object store in my book
[2], so you can evaluate if it might be a fit for you.

Sorry not to have an immediate fix for you.  Could you also raise a JIRA for
us, though, and attach that log to it?

Thx
Dan


> Regards,
> Barry Woods
> P.S. Not sure whether this is the right place to raise issues - pls 
> advise if not.
Indeed it is!

[1] http://code.google.com/a/apache-extras.org/
[2] http://pragprog.com/titles/dhnako


Mime
View raw message