Regressions like this happen all the time in SQL databases. Oracle has (had, now deprecated) a join syntatic sugar (+), which served as a shortcut for the full ANSI left/right joins. I found a bug...
A famous example of this is that some SQL servers are dramatically faster if you specify “where a=b and b=c and a=c” than if you only specify “where a=b and b=c” even though the result set is the same. You’re not supposed to have to care about the procedure, only the specification. But sometimes the abstraction leaks and causes horrible performance and you have to break out the query plan analyzer and study what it did wrong, and figure out how to make your query run faster.
Regressions like this happen all the time in SQL databases. Oracle has (had, now deprecated) a join syntatic sugar (+), which served as a shortcut for the full ANSI left/right joins. I found a bug that made it into an 11g patchset where if a view was created with an outer join, it would return different, potentially incomplete results depending if you used the ANSI syntax or the Oracle syntax. It was only able to be reproduced on a certain version of 11g, and prevented us from deploying a quarterly patch in Prod.
SQL servers are a lot like NVIDIA DirectX11 drivers....full of tiny, use-case specific optimizations, down to for specific games. Especially before the 12g days, it often made sense in Oracle to disable the automatic optimizer and hand-tune any non-trivial queries.
ORM, especially bolted on to a legacy shared database, can suffer immensely if it doesn't play nicely with an existing application, in part because of this, and the other leaky problems described in article.
Edit: Oh my I just realized this blog post was from November of 2002....that bug I described was circa 2010. When the blog was written, there was no such thing as hassle-free database work.
Regressions like this happen all the time in SQL databases. Oracle has (had, now deprecated) a join syntatic sugar
(+), which served as a shortcut for the full ANSI left/right joins. I found a bug that made it into an 11g patchset where if a view was created with an outer join, it would return different, potentially incomplete results depending if you used the ANSI syntax or the Oracle syntax. It was only able to be reproduced on a certain version of 11g, and prevented us from deploying a quarterly patch in Prod.SQL servers are a lot like NVIDIA DirectX11 drivers....full of tiny, use-case specific optimizations, down to for specific games. Especially before the 12g days, it often made sense in Oracle to disable the automatic optimizer and hand-tune any non-trivial queries.
ORM, especially bolted on to a legacy shared database, can suffer immensely if it doesn't play nicely with an existing application, in part because of this, and the other leaky problems described in article.
Edit: Oh my I just realized this blog post was from November of 2002....that bug I described was circa 2010. When the blog was written, there was no such thing as hassle-free database work.