Basic Schema Validation Missing
-
I have a LINQ to SQL Product class, with some properties that are not nullable. Surely this should be implicitly checked before attempting a database update. Why do I have to go and code to check for nulls when the o/r designer should include this in generated code?
-
I have a LINQ to SQL Product class, with some properties that are not nullable. Surely this should be implicitly checked before attempting a database update. Why do I have to go and code to check for nulls when the o/r designer should include this in generated code?
How did you generate your mapping - did you generate a DBML file? By default SqlMetal will attempt to match the nullability of the field, so it won't generate a nullable datatype for a none-nullable field. If you want to check, open up the diagram, select one of your fields and look at the properties. The Nullable field is present there.
Deja View - the feeling that you've seen this post before.
-
How did you generate your mapping - did you generate a DBML file? By default SqlMetal will attempt to match the nullability of the field, so it won't generate a nullable datatype for a none-nullable field. If you want to check, open up the diagram, select one of your fields and look at the properties. The Nullable field is present there.
Deja View - the feeling that you've seen this post before.
Yes, I used a DBML file, but my null problem is on strings. The properties in the designer have Nullable = false, the generated property code has CanBeNull=false in the ColumnAttribute, but the database is the first to complain about a null value.
-
Yes, I used a DBML file, but my null problem is on strings. The properties in the designer have Nullable = false, the generated property code has CanBeNull=false in the ColumnAttribute, but the database is the first to complain about a null value.
Strictly speaking, you should be validating the data before it reaches the database to ensure that it is valid. We use a custom rule manager that lets you specify validation rules that can be run whenever your object changes to ensure that it has all of the relevant entries. This is probably the approach that you want to take here.
Deja View - the feeling that you've seen this post before.
-
Strictly speaking, you should be validating the data before it reaches the database to ensure that it is valid. We use a custom rule manager that lets you specify validation rules that can be run whenever your object changes to ensure that it has all of the relevant entries. This is probably the approach that you want to take here.
Deja View - the feeling that you've seen this post before.
Pete O'Hanlon wrote:
Strictly speaking, you should be validating the data before it reaches the database to ensure that it is valid.
Yes, this is what I have an issue with. Why does the designer bother setting a Nullable=false designer property, as well as adding a CanBeNull=false to the Column attribute, if these mean nothing unless I code for them? Right now I have explicit code that checks each non-nullable string field, but I'm not happy that I have to code such basic validations.
-
Pete O'Hanlon wrote:
Strictly speaking, you should be validating the data before it reaches the database to ensure that it is valid.
Yes, this is what I have an issue with. Why does the designer bother setting a Nullable=false designer property, as well as adding a CanBeNull=false to the Column attribute, if these mean nothing unless I code for them? Right now I have explicit code that checks each non-nullable string field, but I'm not happy that I have to code such basic validations.
With a little bit of trickery, you can check the definition to see if it's nullable or not and have a presave step that checks the entry in your field against the nullability of the column.
Brady Kelly wrote:
Why does the designer bother setting a Nullable=false designer property
That's so it generates the appropriate types for fields like int where you have to specify a nullable version (i.e. int?) if the field can contain nulls.
Deja View - the feeling that you've seen this post before.
-
With a little bit of trickery, you can check the definition to see if it's nullable or not and have a presave step that checks the entry in your field against the nullability of the column.
Brady Kelly wrote:
Why does the designer bother setting a Nullable=false designer property
That's so it generates the appropriate types for fields like int where you have to specify a nullable version (i.e. int?) if the field can contain nulls.
Deja View - the feeling that you've seen this post before.
Hmm, yes. I already have a CheckRequired in my base class, so instead of calling that explicitly from the derived classes, I'll call it for all non nullable column properties found by attribute. It's almost enough. Have you done any work with the Entity Framework?
-
Hmm, yes. I already have a CheckRequired in my base class, so instead of calling that explicitly from the derived classes, I'll call it for all non nullable column properties found by attribute. It's almost enough. Have you done any work with the Entity Framework?
Brady Kelly wrote:
Have you done any work with the Entity Framework?
A little bit. We aren't going to commit to doing anything serious with it until we've had a chance to evaluate the final version. I'm sick of having to change things because MS decides to revamp things between releases.
Deja View - the feeling that you've seen this post before.