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
|
I am trying to save a blank field to the database, using .NET 4, VS2010, C# and LightSpeed 4 (beta). Basically, if a test fails, there are 2 more fields we need filled in -- failure code and reason/description. Failure code is a child table, so all I store is the ID (LS models it as collection). Failure reason is a string (VARCHAR(50)) that is completely optional, even if the test fails, so it will be an empty string most of the time. I have a real aversion to database NULLs, as they are hard to model in code and can lead to all kinds of hard-to-find bugs, so in general my optional fields are defined as NOT NULL with a default value. In the case of a VARCHAR field, that is an empty string. ID fields are usually defaulted to 0. LightSpeed doesn't handle this very well, but at least in the case of the ID field I can set the field to NULL and LS declares that a Nullable field in the model. I can (grudgingly) live with this, it also models as a collection so it seems valid to let it be NULL. However, when I supply an empty string as the string VARCHAR/string field, LS throws a validation exception saying the field is required. I tried setting the database field to allow NULLs with no apparent effect on the generated code (bug?), but either way I get the exception. The field has 2 Validate attributes, [ValidatePresence] and [ValidateLength(0, 100)]. So, it seems to me that a zero-length string would be valid, right? And why is the ValidatePresence still there even when the database is set to allow NULL? (When I commented out the ValidatePresence attribute, I get other errors, so maybe that works -- I haven't figured out what is causing the other errors yet, though.) Help! Dave |
|
|
By default, ValidatePresence considers an empty string to be 'not present.' This is by design, because an empty string typically means the user hasn't filled in the field. You should either remove ValidatePresence, or set its AllowEmptyString option to True. The difference is that if you keep ValidatePresence then LightSpeed will still check for null strings; if you remove ValidatePresence it will allow null strings. Re setting the database field to allow NULLs and why this doesn't affect the ValidatePresence -- I think this is because we only infer a presence validation on initial entity/table creation. Subsequent changes to the database nullability do not affect ValidatePresence. So I think we inferred ValidatePresence based on the table definition when you first dragged it on, and we do not subsequently automatically remove it (because we can't remember whether it was inferred or whether it's honest-to-goodness business logic). |
|
|
AllowEmptyStrings is what I was looking for, thanks. The logic you explained in the second paragraph also makes sense, now that I think about it a bit. Thanks again! |
|
|
In looking at this, I don't see a way to use the AllowEmptyString property on the ValidatePresence attribute via the designer. I can manually add it in the model.cs file, but I really hate doing that. Is there a better way and I'm just not seeing it? Dave |
|
|
Yes, there is -- fear not! Jump into the LightSpeed model explorer tree view, drill down through the entity to the troublesome property within it, and open its Validations folder. You should see a Presence Validation in the folder. Select that Presence Validation and go to the Properties grid. You'll see an Allow Empty String option. Set that to True and you're good to go. (In general, the validation entries you see in the property grid with a property selected are shorthands for common validation cases. If you ever need finer control, e.g. custom error message or validation option, the tree view -- the 'true' view -- is worth a look.) |
|
|
Thanks! I'm not sure how in the world I missed the Model Explorer... |
|