Option 2: Make the error message not be "Invalid object name 'voa_keygen'.", make it say "Entity X needs to have a primary key"
Reason I say that is I just got this nice friendly guy again and the error is so obscure you don't really know why you're getting it. I mapped the View in last night before I left, and I got the error this morning so I had to go back through my steps on what I changed yesterday.
I guess what I'm saying is that this WILL cause the model to fail, you wont be able to use the model (not just the class), so put up a roadblock for us so we're not spinning our wheels trying to figure out what happened :) Don't let us get to that point.
Steve
5 Answers, 1 is accepted
What we actually provided with one of the latest internal builds is the ability to plug in the existing Validation Framework (and rules) into a mapping defined using the Code Only API. And while it isn't exactly the same as your case it can be tweaked and used.
What I have prepared is a simple class library that has the AdventureWorks database mapped (and has a couple of warnings and errors in place). I then added a new property in the csproj called ValidateMapping that is set to true. I also changed the build action of the rlinq file to EmbeddedResource and added a new Fluent Metadata Source, that in its CreateModel override just returns the mapping from the rlinq file.
I did this so that your assembly is enhancer using the metadata source as this is the way to plug in the validation framework. (BTW I have set it up so that it is using the build in validation rules, however you can use this approach to implement your own, and even enforce a convention on your model and colleagues, you just need to override GetValidationProvider()).
The result is that the errors and warnings shown in the designer are now compile time errors.
Please have a look at the attached project and let us know if this will work for you.
Serge
the Telerik team
However this is good to know :) So what types of things can I validate in here? Could we validate X object has Y set of navigation properties? Right now I have a unit test to manually check model state...so I expect that X entity has Y properties and Z navigation properties. That way if I re-map I can make sure the properties are all back as they were (casing, naming, etc).
To the root issue though, shouldn't something that causes the entire model to fail at runtime guaranteed be a compile-time error?
Usually it is fair to say that a compile time error is what you would expect. However if you model is in a state that leads to a failure you will get an error early enough, that is the first time you access OpenAccess.
As to what kinds of things you can check, you get to perform validation on the whole Metadata Container. You can implement rules that are basically visitors and can hook up on every type of MetaItem, be it a MetaPersistentType, a MetaMember or even the MetadataContainer itself.
I hope this helps.
All the best,
Serge
the Telerik team
"it is fair to say that a compile time error is what you would expect"
Right, I guess I would expect that when the project compiles...it'd work :)
The underlying problem is that anything you do with OA will show the Yellow Screen of Death "Invalid object name 'voa_keygen"...with that error being totally generic. At the very least it should tell me which entity needs the PK set, no?
We should definitely improve the error message, as it really isn't pointing into a possible solution. Just stating a generic error. And as to compilation, it isn't always a clear bet that compilable code is working. Or tested code is working for that matter.
I would like to thank you again for your valuable input.
Serge
the Telerik team