Yes, this would be a useful feature.
> Since we're extending from CayenneDataObject it'll never be 100%
> transparent
In 1.2 client-side objects are almost POJO already. Persistent
interface is so simple that having a framework superclass is no
longer a necessity, and I think I'll trim down "Persistent" even
further... or get rid of it
all together. So things may change.
> What it all boils down to is transparency.
Sure. One problem is that when assembling a composition outside of a
[Data|Object]Context we can't transparently connect reverse
relationships (aside from some class generation tricks that tend to
scare people). Actually now I thought of a somewhat ok solution -
connect missing reverse relationships later, when an object is
finally registered. Still an inconsistency between registered and
unregistered objects remains, though a smaller one. Any better ideas?
> So, I'm willing to step up and help out with this, but I'm going to
> need some guidance.
My own immediate goal is Persistent/ObjectContext/Multi-tier stuff,
where this feature would have to be present as well. But migration
from CDO to Persistent (or POJO) will be a lengthy process, so it
would be cool if you can do it on the CDO side.
As for the actual implementation... Unlike POJO, CayenneDataObject
allows for many ways to transparently handle this situation. For to-
one relationships nothing special is required (I think). For to-many
you may need to define a new variety of "willConnect" that would
create a ToManyList. That's something Gili's patch was meant to
address, only willConnect would allow to do it lazily on demand and
without class generation. Also it is only meaningful in this wider
context that we are discussing now.
On the DataContext side, you'd have to do graph analysis inside
"registerNewObject" to (a) pull all TRANSIENT objects in the graph
being registered into the context and (b) detect missing connections
for reverse relationships and connect them.
One catch with this is that a directed graph (digraph) that you'll be
processing may not be traversible from a single root object... So it
will be user's responsibility to give us graph that we can process.
An example:
*** Working Example:
Artist a = new Artist();
Painting p = new Painting();
a.addToPaintings(p);
// this will find a painting related to artist and pull it in...
context.registerNewObject(a);
*** Broken Example:
Artist a = new Artist();
Painting p = new Painting();
p.setArtist(a);
// this will not register a Painting as Artist knows nothing about it..
context.registerNewObject(a);
I can't think of a solution beyond class generation ... it would suck
though. Or force users to register ALL objects they might have
created. Not to transparent either.
Andrus
On Sep 8, 2005, at 10:38 PM, Kevin Menard wrote:
> Okay, I think this has been on the radar for a while. For me, it's
> the single-most annoying thing when working with Cayenne. I'm sure
> I'm not the only one that feels this way. So, I'm willing to step
> up and help out with this, but I'm going to need some guidance.
>
> For those that don't know what I'm talking about, the basic issue
> is that that if you try to associate two unregistered
> CayenneDataObjects with each other, Cayenne will throw an
> exception. Andrus has done some nice work in 1.2 whereby now if at
> least one is registered with a DC, then the other will be auto-
> registered. What I'd like to see is a way of delaying
> registration. So, two unregistered instances can be associated
> with one another, then when one gets registered it cascades down.
>
> There are a lot of reasons why this would be useful. Composition
> is an immediate one that comes to mind (the construct of one CDO
> cannot create and link another CDO). Another is that some
> frameworks, such as Tapestry, make it hard to register an object
> with a DC when it's created. What it all boils down to is
> transparency though. Since we're extending from CayenneDataObject
> it'll never be 100% transparent, but I don't want to have to think
> about satisfying some Cayenne requirement whenever I call a set or
> addTo method.
>
> I remember there being quite a bit of discussion about this in the
> past. I'd like to throw it back on the table and see who's
> interested in getting this going.
>
> --
> Kevin
>
>
This archive was generated by hypermail 2.0.0 : Thu Sep 08 2005 - 23:35:39 EDT