Fabricio Voznika wrote:
> How are you guys doing validation in your objects using cayenne?
Uhmm.. *looking at floor*..good question! :-)
There's not much (translation: almost nothing) in place for this right
now. The event stuff is there and works but it's not fully used yet.
> The way I like to do it is to have a validate method in every
> object, and then call this method before the transaction commits. This
Makes sense.
> The way I tried to do is to make my objects implement
> DataObjectTransactionEventListener.willCommit(DataContextEvent) and do
> all the checks there. But I haven't found a way to abort the commit from
> there. If I throw an exception, it just get logged (see
> Invocation.fire(Object[])) if I call DataContext.rollbackChanges() it
Logging and subsequently ignoring any exceptions during event posting was
simply the first thing that came to my mind because I definitely didn't
want to abort the event loop just because one receiver bombed. Handling
the greater meaning of the exception is not the Invocation's concern
anyway, and the whole event machinery is meant to be as generic as
possible.
One possibility would be to collect any raised exceptions and..do what?
- return them (doubtful)
- throw the first one
- throw an EventInvocationException that has the collected exceptions
attached
- ???
This is made more difficult since we plan to have distributed (and
therefore most likely asynchronous) events in the future.
Another idea: we (I, sigh ;) could make continuation dependent on the
event, i.e. add the option to either ignore exceptions, or abort
lazily/immediately, effectively making the resposibility configurable
(would fit in nicely with the async distribution by proxying the event). I
guess I need to think about all that some more, comments welcome.
> Is there any other way of doing something like this? How are you
> guys doing?
I think your best bet (for now) will be to manually check objects right
after modification. We definitely need a semi- (if not fully-)automagic
strategy for that before 1.0, but unfortunately there is no 'definite' way
to implement it since it often mixes business rules (model), transaction
logic (model/controller) and (in a web app) web application state handling
(controller). Even a manual way to abort 'the current transaction'
(whatever that is ;) might be a good first remedy, but we'll need to
discuss this with Andrus when he's back.
If you (or anybody else on this list!) have any suggestions about possible
validation strategies that you'd like to see I'd love to hear about them,
preferrably on -devel, replyto: is set accordingly.
thanks
Holger
PS: please keep in mind we also need some things to do for 1.1 :)
This archive was generated by hypermail 2.0.0 : Sun Jul 27 2003 - 13:32:57 EDT