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 guys, trying to understand the rules behind the designer autogenerating ValidatePresence attribute. I'm looking at properties which have Is Nullable == false (the Designer rightly picked it up from the database), and I see that through the model most properites have ValidatePresence == "true", but some (not all) strings have "false", and I'm not really sure how did this happen. |
|
|
|
|
The rule for inferring Validate Presence from a database column definition is: * If the column is a string (char, varchar, etc.) or BLOB, and it is nullable: Validate Presence = false * If the column is a string or BLOB, and it is non-nullable: Validate Presence = true * If the column is any other data type: Validate Presence = false If you're seeing something different, it's possible the validation has been added or removed by hand. |
|
|
|
|
OK, I think this is what happened (just tested in on one column). Some string columns initally were nullable in the database and also the model followed this on entity creation. Later these columns were proclaimed NOT NULL in the database. The designer's "Update From Source" changed IsNullable to false, but didn't create the ValidatePresence attribute. BTW, in testing by accident I set ValidatePresence attribute = true on a boolean property (pure bool, without nullable generic, IsNullable = False) and this caused my entities to be invalid if that bool property was set to "false". An error "property is required" was given always. Not sure this is an expected behavior... |
|
|
|
|
Thanks for the additional info. I've logged a bug for the designer update behaviour, though I have some concerns about whether we can be confident that we're not about to blow away a user-created validation. Regarding boolean properties... this is expected behaviour... kind of. Basically Validate Presence says "check that the value isn't still the CLR default" -- e.g. not null for strings, not 0 for numbers... and not false for booleans. So by a process of remorseless logic we end up with the rather silly result you've found: that the only value considered "present" for a boolean is "true." However, as the only alternative is to make a special case that says "Validate Presence is ignored for booleans," we'll probably leave it as stands. |
|
|
|
