I ran into an interesting situation which was the result of my own stupidity yesterday, but I thought I'd raise it as a possible enhancement. This involves EFDAL.
I was running into a problem where I was trying to use a "derived" property (i.e., one not defined in the schema, but in the partial class generated from the schema for an object) in an EF Linq query. That's not supported under EF, but one of the
potential workarounds I tried involved creating a property in the nHydrate schema with the same name and type, but not generating it (that didn't work, BTW; the solution is simple: don't use derived properties :)).
When I added that (bit) field to the schema I defined it as NOT NULL with no default value. That was an error because the table in question already had data in it, and you can't add a NOT NULL w/no default value field to a table containing data. However,
since I had marked the new field as "not generated" I didn't bother to run the installer; I just recompiled the generated projects. So I had an error lurking in the automatically-generated update scripts.
I then removed the new bit field from the schema and made some other changes which necessitated running the installer. When I did that it gacked at the stage where it tried to add the NOT NULL w/no default value bit field...even though I'd later removed
At that point, conceptually what I wanted to do was to roll back the schema definition to a point before I'd added the new bit field. I think this could be done by forcing the "generation number" to reset to a particular value. But I couldn't figure
out how to do that, so I just went in and modified the automatically updated script file which added the bit field to add it as a NULL field w/no default value, which is valid.
Is it possible to roll back a schema file? Could that be a potential feature? It wouldn't be necessary if manual edits to the automatically-generated update scripts are preserved when the schema is regenerated. Are they? I guess I'll find out soon enough
given all the changes I'm making to the schema :).