Page 1 of 1
Posted: Thu Feb 25, 2010 5:16 pm
by Malcolm
Weird question ...
Let's pretend I've got a data model in the form of a huge SQL Server DB that I connect to from a massive .Net app. Is there anyway to get .Net to fire off compiler errors if the data model gets changed? I know this is essentially asking the compiler to verify the DB, but anyone know of a way to force that w\o having to write your own independent DB verifier?
Posted: Fri Feb 26, 2010 12:21 am
by TPRJones
Let me start by saying I know nothing about .Net.
That having been said, if you want to do it at the compiler level then it seems it would have to be a feature specific to the compiler you are using. Are there multiple .Net compilers out there, or does everyone use something Microsoft puts out for that? That'd be where to check.
But if you have to, making a verifier shouldn't be hard. Just copy the table structure (empty of the data) to a separate DB, then compare the structure of the current against that model. If it finds changes code it to give you the details and the option to reset that verification DB to the new structure. First run you kill it and recode, second run you tell it to reset the model and keep going.
Of course, maybe that would be hard in .Net. I wouldn't know. And with luck I'll never have to learn. :p
Posted: Fri Feb 26, 2010 12:16 pm
by Malcolm
Here's the issue --
All that DB/table consistency checking is built into Entity Framework. The problem is that EF doesn't generate the most efficient SQL queries, particularly updates. Changing any property of an entity changes its state to "modified." When you update modified objects, EF writes a query that updates every fucking attribute, even those that weren't changed.
Best solution I can think of (at least currently) is to ...
1) cache a copy of every entity's fields & their corresponding values
2) let EF generate the shit query
3) check if any fields have changed
3) modify EF's shit query before it gets ferried off to the DB, killing any mention of any attributes that haven't changed
It begs the question of whether or not there's some deeply-hidden configuration setting that I can alter to accomplish the same goal. Then again, it is MS.
Posted: Fri Feb 26, 2010 2:16 pm
by TheCatt
That's a really common issue with ORMs in general. Are you having performance issues?
Posted: Fri Feb 26, 2010 2:34 pm
by Malcolm
TheCatt wrote:That's a really common issue with ORMs in general. Are you having performance issues?
It's one possibility of about a bajillion. We're investigating whether it's the app, the DB, or whatever. There's camps forming on all sides of the issue.
Posted: Fri Feb 26, 2010 2:57 pm
by TheCatt
The single row update should be off a keyed column (or columns <ick, but that's another topic>), and should have a really low execution cost.
It's really easy to capture your explain plan and check out its cost in SQL to see how much of an impact it's having.
Posted: Fri Feb 26, 2010 4:18 pm
by Malcolm
Could also be the way we're using that damn .Net parallel library.
"The library contains sophisticated algorithms for dynamic work distribution and automatically adapts to the workload and particular machine. "
Nothing gives me more confidence in your load balancing methods than hiding them from me & forcing me to decompile your .dll to verify them.