Splitting my comment on Lachlan's patch into smaller manageable
pieces. See comments on ObjectContext inline...
> Index: framework/cayenne-jdk1.4-unpublished/src/main/java/org/
> apache/cayenne/BaseContext.java
> ===================================================================
> + public Persistent localObject(ObjectId id, Object prototype) {
> +
> + if (id == null) {
> + throw new IllegalArgumentException("Null ObjectId");
> + }
> +
+1, but note that there are some slight differences between
DataContext and CayenneContext implementation. Don't recall all the
details, but it would be nice to diff them and see what we can do
about them.
> Index: framework/cayenne-jdk1.4-unpublished/src/main/java/org/
> apache/cayenne/ObjectContext.java
> ===================================================================
> /**
> + * Creates a nested context
> + */
> + ObjectContext createNestedContext();
> +
> + /**
> * Returns EntityResolver that stores all mapping information
> accessible by this
> * ObjectContext.
> */
-1: I think we should start with implementation of nested contexts on
the client, before declaring it in the interface (i.e. before
announcing it to the users). Also I've been doing some work as a part
of CAY-739. So maybe this method will be moved to the *Utils class
all together.
> /**
> + * Returns an object local to this ObjectContext and matching
> the ObjectId.
> + * <p>
> + * Unlike ..ink #localObject(ObjectId, Object)}, this method
> will only do "mapping"
> + * (i.e. finding an object with the same id in this context).
> + * </p>
> + */
> + Persistent localObject(ObjectId id);
...
> /**
> + * Returns an object local to this ObjectContext from the
> given object.
> + * <p>
> + * This is essentially a convenience method for ..ink
> #localObject(ObjectId)}.
> + * </p>
> + */
> + Persistent localObject(Persistent aPersistentObject);
> +
-1: IMO the interface must be as lean as possible to simplify alt.
implementations and decorators. So convenience (in other words
derived from other) methods should preferably be defined outside the
interface. I think this is such case.
>
>.. -141,6 +163,14 @@
> void commitChangesToParent();
>
> /**
> + * Determines if there are any changes in this context that
> can be flushed to the
> + * parent DataChannel. i.e., determines if ..ink
> #commitChangesToParent()} would
> + * flush any changes to the parent DataChannel or, likewise, if
> + * ..ink #commitChanges()} has changes to cascade through the
> stack to the database.
> + */
> + boolean hasChanges();
> +
> + /**
> * Resets all uncommitted changes made to the objects in this
> ObjectContext, cascading
> * rollback operation all the way through the stack.
> */
+1: while it is somewhat redundant, it should allow implementors to
optimize analysis of graph changes.
Andrus
This archive was generated by hypermail 2.0.0 : Mon Mar 26 2007 - 11:37:32 EDT