On 5-okt-04, at 16:52, Cris Daniluk wrote:
> Why not let the database do it and simply have the db adapters better
> equipped to handle the unique constraint exception?
> -----Original Message-----
>> From: Gentry, Michael [mailto:michael_gentr..anniemae.com]
>> My approach for the e-mail address would be to use
>> validateForSave() to query the table (if the object hasn't
>> been inserted yet -- look at
>> PersistenceState.NEW) and handle it there. That way you don't
>> have to sort out the exceptions and can give a nice error
>> message to the user.
Me too I have some doubts.
The DBMS handles the persistence of your objects, and its own
consistency.
Even if you handle possible duplicates in your validateForSave(), I
think you could still be forced to handle an (the unique contraint)
exception triggered by the DBMS at commit time. Other aplications or
threads could have just inserted or removed the eventually triggering
row. This depends on tactics, and - case per case - the complexity of
your application architecture and overall deployment. Maybe therefor
depending, for contraint checks, on the ORM framework that is Cayenne
is not such a good idea.
What does sound interesting though, is a way to create wrapper
Exceptions for common DBMS "runtime" exceptions like these. These
could be a refinement of the CayenneRuntimeException. For example, the
DataContext or the Query could then be configured to raise an exception
if no rows are found for a Query.
But then again, because each database product differs, making
exceptions more semantic probably implicates work to be done at the
adaptor level too. Or one could choose to have a look at the SQL92 ISO
standard error codes and think what we could do using these. Etc...
choices, choices...
Just my 0.02
I have some experience with EOF, and now looking at Cayenne. So i'm not
really ready yet for in depth discussions. So I could be wrong,
Stefaan Huysentruyt
This archive was generated by hypermail 2.0.0 : Tue Oct 05 2004 - 11:51:27 EDT