> By doing the insert and caching the exception (even if it's likely to be the
> more common result), you don't have to do the search for a matching row at
> all. It's done for you implicitly by the unique key check the RDBMS does
> before inserting the row.
I was planning to override save() to make it a bit smarter, but after a
some digging, it looks like that's going to be more work than just
catching the exceptions.
But that brings up another question: how would you update the existing
row if the unique key that caused the exception is not the primary key?
In my example, the 'id' field wouldn't be set since it's the
auto-increment primary key and therefore wouldn't toss the exception.
The 'md5' column could indeed cause it, which, as it turns out, was the
cause that spawned this thread.
So I create and populate a row with data that is not unique, then save.
The save will toss an exception, and while the idea is to trap that
exception, don't I still need to find & fetch the row, update the data &
then save()?
I could do a "manual" update on the parent Table object, but that seems
to defeat the purpose of the Row. Or am I missing how Table_Row is
supposed to be used?
-Brad Waite
没有评论:
发表评论