I think this is a case of something seeming unique, but really
isn't. You can have a business rule that says they don't want
duplicates, but hard-coding business rules into the DB can lead to
problems in the future. Use Java to enforce the business logic, not
the DB.
Initiate religious argument .............. NOW.
Regardless of the business logic debate, one HUGE caveat here is that
you cannot properly resolve several race conditions in EOF
implementing logic purely in Java. In particular, enforcing
uniqueness is a really nasty one. If you have multiple instances or
multiple EOF stacks, you will always be open to a race trying to keep
values unique without also having a unique constraint on your database
(where the database can enforce that atomically).
ms
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
