+1 to adding a db-level constraint for this, and for also handling/validating it at the API layer.
-Darius On Tue, Apr 3, 2012 at 9:12 AM, Burke Mamlin <[email protected]>wrote: > I wasn't suggesting that database constraints be used in lieu of API > constraints (the API would return an duplicate tag exception regardless); > rather, just as a way to ensure that (1) bogus data don't sneak in as they > tend to do and (2) preventing the API from having to handle the case where > duplicate tags for the same object exists in the database (which, if these > tags have IDs and UUIDs that might be referenced elsewhere, may not be > straightforward to rectify). > > I don't believe the API should ever accept or return a list of tags > containing duplicates. > > -Burke > > > On Tue, Apr 3, 2012 at 11:46 AM, Michael Seaton <[email protected]> wrote: > >> We _could_ try to enforce this at the db level, but I don't think I'd >> want the user to get an exception if they try this - it's not like it would >> really hurt anything to have 2 tags. It might be easier to just add >> application-level checks to only add a new Row to the table if the >> definition_uuid / tag combination doesn't exist. Either way, we could >> inform the user that the tag they have added already exists and continue as >> normal... >> >> >> >> On 04/03/2012 11:24 AM, Burke Mamlin wrote: >> >>> Shouldn't tags be unique -- i.e., you shouldn't be able to create >>> duplicate tags (same string) on the same object, right? Can we enforce >>> that at the database level? >>> >> >> > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
