3 ms·

I can see that people have already heaped plenty of fuel on the fire, but.. The amount of time I have wasted babysitting Microsoft's EntityFramework stuff :-/.

I can see that people have already heaped plenty of fuel on the fire, but.. The amount of time I have wasted babysitting Microsoft's EntityFramework stuff :-/. That is stackoverflow-googling 'why does EF suddenly behave this way, and how to I get it to stop?'. In my most recent adventure, it had suddenly started to fight with some of our foreign-key delete-cascades. That is, even though EF had itself generated migrations that told SQL-Server to use delete-cascade, this would catch EF off guard, and it whould suddenly scream 'there used to be rows in this table but now they are gone!' Stackoverflowing suggested to bypass it by specifying an alternate delete-cascade policy (presumably one where db was allowed to cascade and client would pretend everything was OK.) That .. sort of worked, but now our unit-tests were failing, because they didn't like that new cascade-rule.. So now we have conditional compiles, where our unit tests compile with the rule set one way, and production code sets it the other way.. I have no idea what our tests now claim about our code, relative to production.. Hooray for ORMs. Not.

fifticon 3y ago
Another favorite of mine: EF will sometimes generate constraints on your tables or columns, that can't really work. But the generated migrations are generated with drop-reversers that don't work (ie if you try to execute them, you get SQL-errors.) BUT, EF also generates random names for these constraints, so you can't just drop them by hand - you don't know what they are called, and they will have different random names on different db instances! So you (that is, I) end up having to write convoluted stored procedures, that query the db for 'what kinds of constraints do you have that satisfy these requirements, what are they called?', THEN you can remove them in an order that makes sense (instead of the autogenerated nonsense that won't execute..) Oh, and EF's code for handling its own migration-table used to be buggy; they used to have a column they later got rid of, and some of their code would fail on this column either being or not being there. My final gripe (for today) is that their migration-table doesn't include a timestamp for when the migration was executed. This has caused me headaches, because sometimes bugs in client data would depend on, whether a migration had happened early or late, since it would determine against which version of your db model client data was processed. sigh.

fifticon 3y ago

Another favorite of mine: EF will sometimes generate constraints on your tables or columns, that can't really work. But the generated migrations are generated with drop-reversers that don't work (ie if you try to execute them, you get SQL-errors.) BUT, EF also generates random names for these constraints, so you can't just drop them by hand - you don't know what they are called, and they will have different random names on different db instances! So you (that is, I) end up having to write convoluted stored procedures, that query the db for 'what kinds of constraints do you have that satisfy these requirements, what are they called?', THEN you can remove them in an order that makes sense (instead of the autogenerated nonsense that won't execute..) Oh, and EF's code for handling its own migration-table used to be buggy; they used to have a column they later got rid of, and some of their code would fail on this column either being or not being there. My final gripe (for today) is that their migration-table doesn't include a timestamp for when the migration was executed. This has caused me headaches, because sometimes bugs in client data would depend on, whether a migration had happened early or late, since it would determine against which version of your db model client data was processed. sigh.