Cris,
It is pretty clear now. Still I am unsure why this is a problem...
When you get a commit exception you have to handle it somehow, right? So
normally you would either (1) revert the DataContext, show an error
message and let the user to start from scratch, or (2) do not revert the
DataContext and let the user to fix the errors, preserving his uncommitted
changes in memory.
In the second case (which is more common and user friendly) you simply
won't do "context.createAndRegisterNewObject" (taking your example) for
the second time, letting the user to edit an already entered artist...
DataContext methods hasChanges(), newObjects(), etc. will let you inspect
DataConext state in a generic fashion if this is needed, but normally a
presense of an Artist ivar somewhere (depending on what view technology
you are using) should be an indicator that a new one is not needed.
Any reason why this won't work for you?
Andrus
Another possibility is
> Andrus,
>
> The most concise way I can come up with to describe the issue is
> something like this:
>
> DataContext ctx = DataContext.getThreadContext(); // pulls context from
> user Session
> Artist noName = (Artist)
> context.createAndRegisterNewObject(Artist.class); noName.setName(null);
> // required field
>
> ctx.commitChanges(); // throws runtime exception...
>
> The exception is handled, but the DataContext's state isn't reset. The
> same user makes another request:
>
> DataContext ctx = DataContext.getThreadContext(); // pulls context from
> user Session
> Artist picasso = (Artist)
> context.createAndRegisterNewObject(Artist.class);
> picasso.setName("Picasso"); // required field
>
> ctx.commitChanges(); // still throws runtime exception
>
> The DataContext attempts to commit the Artist noName first, before
> trying to commit picasso. It does not reset itself to a safe state after
> a failure.
>
> What I'm trying to do is effectively trap the state and react
> accordingly on the subsequent request.
>
> Hope that is a little more clear,
>
> Cris
>
This archive was generated by hypermail 2.0.0 : Wed Dec 15 2004 - 14:48:25 EST