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 [EMAIL PROTECTED] #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 [EMAIL PROTECTED]
#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 [EMAIL PROTECTED]
#commitChangesToParent()} would
+ * flush any changes to the parent DataChannel or, likewise, if
+ * [EMAIL PROTECTED] #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
