mirror of
https://github.com/doctrine/orm.git
synced 2026-03-23 22:42:18 +01:00
Change of strategy: Supported vendors per feature #6168
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @iluuu1994 on GitHub (Feb 6, 2019).
Originally assigned to: @Ocramius on GitHub.
This has been on my mind for a while.
There are some fundamental features Doctrine doesn't support for one reason: One of the supported databases doesn't support it. An example would be
LIMITandOFFSETfor sub-queries.This is problematic because the only alternative is to use native queries. If your whole application is built on Doctrine filters/query builders/gedmo this can be very difficult. Since
->getQuery()->getSql()creates unpredictable aliases you also cannot easily wrap it into a CTE either.I suggest one potential solution: The user can configure a set of supported databases. Doctrine checks at runtime if any used feature is compatible with all of the supported vendors. If it isn't you'll get an exception. So for example, if I were to use a
CTEin my query but my configuration says I support MySql, Doctrine would complain and tell me that this query won't work on MySql even if I'm currently connected to a Postgres database which does supportCTEs.Doctrine would continue to be predictable this way. If a query compiles, you know it will run on your supported platforms.
The main benefits would be:
This is just a though. What do you think?
@Ocramius commented on GitHub (Feb 6, 2019):
This increases the maintenance burden by a lot: not really feasible, in my
opinion.
On Wed, 6 Feb 2019, 13:49 Ilija Tovilo <notifications@github.com wrote:
@iluuu1994 commented on GitHub (Feb 6, 2019):
@Ocramius Can you elaborate why you think so?
Clearly, adding more features to any system will increase the maintenance burden. But that's the same for any Doctrine feature, regardless if it's supported by all database vendors or not.
@Ocramius commented on GitHub (Feb 6, 2019):
The problem is with dealing with the same tool in different permutations of
configurations that work/don't work depending on target environment: that's
extremely fragile and requires a degree of additional effort when dealing
with reported issues.
On Wed, 6 Feb 2019, 14:30 Ilija Tovilo <notifications@github.com wrote:
@iluuu1994 commented on GitHub (Feb 6, 2019):
@Ocramius
I understand. That's already the case to some degree. For example, Sql Server does not allow sorting by aliases. Doctrine will happily compile the query, run it and throw an exception. These kinds of things are indeed hard to predict.
But again, I don't see how this is any different from existing features. Maybe this kind of discussion should be held on a feature to feature basis along with a deeper analysis of what database vendor supports it and under what circumstances.
I'd be happy to contribute to Doctrine. But I'm not ready to invest a bunch of time for the feature to be rejected because it won't work on some database nobody uses. I hope you can see my view point.
@Ocramius commented on GitHub (Feb 9, 2019):
I'm closing as
won't fixhere: we are already resource-starved when it comes to maintainers, and complicating the set of included features "conditionally" is an absolute no-go, as we already have enough people asking "why does X not work on Y" with the current set of functionality (where many slipped through without us being strict enough about baseline supported permutations).See it from the maintainer PoV too ;-)
@iluuu1994 commented on GitHub (Feb 9, 2019):
Thanks @Ocramius for your perspective.
I understand. I'm not suggesting for you to implement new features. I'm interested in implementing some features myself but I know that they won't work on all platforms. Of course, the maintenance burden always falls back on you so I definitely hear what you're saying.
Why? Isn't it better for something fundamental to work 90% of the time than 0% of the time? People already expect features that their database supports to work.
I don't wanna seem unthankful. Doctrine is great. I really appreciate you guys. Ultimately I'm just trying to make Doctrine better by resolving some of the issues I've encountered countess time over the years.