Andrus Adamchik <andru..bjectstyle.org> wrote:
> If you want to play with ContextCommit class to defer "read-only"
> exception for MODIFIED objects till the object is cleared
> (ContextCommit, line 420), the patch is more than welcomed.
As near as I can tell classifyAsWritable() doesn't do anything meaningful other than generate the exception. writableObjEntities is not used anywhere.
Adding the following code after line 420 would seem to accomplish the same purpose if I follow what's going on (assumption: the object is marked COMMITED if no potential database changes were detected).
Class anObjEntityClass = o.getObjectId().getObjClass();
ObjEntity anObjEntity = context.getEntityResolver().lookupObjEntity(anObjEntityClass);
if (anObjEntity.isReadOnly()) {
if (PersistenceState.MODIFIED == o.getPersistenceState())
throw attemptToCommitReadOnlyEntity(anObjEntityClass, anObjEntity);
}
I'm including a patch against 2003-09-25 that has the above code and also replaces the check from classifyAsWritable() with a comment to look in prepareUpdateQueries, but I can't help but wonder if classifyAsWritable() and writableObjEntities should be completely removed as well.
It also seems possible for attemptToCommitReadOnlyEntity() to throw a more specific error on which object caused the problem (perhaps identifying it by primary key or ObjectId) since the specific DataObject instance is available at this point.
[ContextCommit.java.diffs]
This archive was generated by hypermail 2.0.0 : Thu Sep 25 2003 - 16:42:47 EDT