This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Am I right in thinking that if I have defined a unique index in the db, that there isn't much point in adding a LS unique validation? Looks to me like the unique validation issues a count query before committing the uow - i'm happy to rely on the db unique index to save this additional db hit... am i right? cheers |
|
|
You may be right for certain applications, but in general I'd disagree quite strongly. The point of defining the unique validation would be to detect and inform the user of the specific condition so they could correct or cancel it, rather than getting a SqlException and having to figure out what went wrong and which of the batch of 93457 entities caused it. If this isn't a concern (e.g. you have an ops team who are able to work with database error logs, and are able to perform their own diagnostics to sanitise the data when an error does occur), then fair enough. But most users would probably prefer the clearer diagnostics and pre-commit warnings that validation can provide. |
|
|
Just to add my 2c here, the point of having a unique validation in your model is because it is a rule of your domain and you are enforcing it as such. The point of having a unique index in the database is for data integrity reasons of the data model. Now they may be for the same business reasons or equally they may not. As Ivan pointed out - having the unique validation allows you to give a clear indication to an end user that this is a rule being enforced by the domain model as part of this systems behavior.
Jeremy |
|
|
yep, makes sense. In my case I've got a model sitting behind a services layer so there's not much point in providing nice validation messages if uniqueness is not maintained. If uniqueness is not maintained then there's a big problem with the way that a) the services are being called or b) the logic inside the services - and either way, i just want things to blow up - non-uniqueness of this property is a state the entity should never be put into. so i will just drop the model validation and rely on the db blowing things up if things ever get into that non-unique state. thanks |
|