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
|
Hi I have a single table inheritance hierarchy for Users. On the base 'User' entity I have an email address field that has the unique validator set to true. When I try to create a new derived user with a non unique email address, the validation will pass but I expect it to fail. I notice the count query emitted includes the derived user type in the WHERE clause which effectively checks for uniqueness of the email address for the derived user type only, not across all users (even though it is a base property). Is this a bug or am I misunderstanding how this should work? Cheers. BTW Have tried with 3.11 and 4.0 versions with same result. |
|
|
We're calling it a bug. Although it's conceivable someone might want to 'namespace' the unique constraint by type, it seems pretty weird, and it shouldn't be the default. We've changed it so that it will now query for the type of entity which declares the field being validated, e.g. the base User entity instead of the derived type. |
|
|
Excellent, thanks Ivan :-) |
|
|
Hi Ivan I've tried your fix in the latest nightly build (21 July) and notice the validation is still passing (with non-unique email addresses) but a validation exception is now thrown on save changes (previously this would not occur and the database would throw an exception). This is consistent for base and derived types as you have fixed the count query where clause. Are you able to add a validation error to the errors collection for this so the entity fails validation and we avoid the exception? Cheers, Richard. |
|
|
I'm not sure I understand the situation here. Are you saying that the validation is not reporting an error at some point when it ought to, and then later *does* report an error during SaveChanges? If so, this is probably because the entity is not yet part of a unit of work during your initial check. As a uniqueness validation performs a database query, it can only be run once the entity is associated with a database, i.e. when the entity is part of a UOW. |
|
|
Yes you are quite right. My validation pattern was not quite right. I was checking IsValid before adding the user to my repository and saving. Checking IsValid after adding to the repository has sorted out my bug ;-). Thanks again for your help.
|
|