New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RFC] Follow-up on doctrine/collections
Order enum
#11313
Comments
|
Anybody who was using
But the enum isn't working yet:
This can be overcome by using
|
@ThomasLandauer using @derrabus in doctrine/collections#389 (comment), I suggested we give the ORM a chance to upgrade, but I failed to make my point, so let me elaborate. What makes that upgrade so special that we should change the way we do things? I think the main difference with other PRs where we add an API and immediately deprecate the other API is that we expect the users of |
It's a bit unfortunate that the ORM uses constants from a different package in their public API. For ORM 2.19, we could add replacement constants to the ORM codebase. Supporting the |
Also, we have to be careful: Collections is not the only abstraction that we're dealing with here. When talking about the query builder, we're probably closer to the Persistence abstraction which also declares orderings as strings at the moment: It would be a bit weird if the query builder and the repository used different abstractions for ordering stuff. |
I wouldn't switch, I'd support both for a while to give users time to adjust their code. Should be easy enough to accept That said, the current situation leaves people with either a deprecation (which is very annoying in PhpUnit) or very ugly code in the form of something like this:
...where previously this much shorter and more readable version was usable:
Then either the deprecation should go (because you can't fix the deprecation in an acceptable way in 2.x) or the functions requiring a string should also accept the enum, as I just suggested. |
...thus forcing a double migration on all of us, migrating to |
I mean, we could un-deprecate the constants, which basically means that Collections 3 would ship two constants it has no use for. I could live with that. |
Preferably the constants would remain gone in 3 as you're otherwise going to be stuck with them sort of forever. I would just like a better migration path than we have now. For example (without really looking into the current code) we could consider introducing the This would interlock the major versions of Collections and ORM, but I doubt that's really a bad thing (ORM 3.x only works with major X or higher, ORM 2.x only works with major Y or lower). Alternatively I don't really see why we wouldn't support the enums in 2.x, it can't be that much work to support both...? |
I think, I can live with the maintenance burden of two unused constants, really.
Then don't use the constants for the query builder or metadata mapping. Use strings, as it is officially documented. The constants are part of the Collections package, meant for use with the The "migration path" that you're discussing is actually a workaround for people that have used those constants in an undocumented way, outside of their scope. By keeping the constants around, we would give people who want to remain on ORM 2 (for what reason ever) the possibility keep everything as it is. Why's that a problem? |
Fair enough, I forgot about that perspective and indeed this will likely not affect that many people 😄 |
@greg0ire sorry for taking long to respond, I was on vacations :) You can take ODM out of equation for two reasons:
So feel free to do whatever is best for ORM here :) |
To chime in here: while it might be outside their scope, it is not undocumented. See https://www.doctrine-project.org/projects/doctrine-orm/en/3.0/reference/working-with-associations.html#filtering-collections, where the constant is used in the official documentation. edit: after submitting this, I see it is actually a Criteria method, and not an ORM method... It is confusing, caused by all those untyped strings 😄 I would love to see either the enum to be supported, or an additional enum in the ORM namespace itself. |
Just my two cent, but I agree with this point. So far I solved the "deprecated" issue by using again the string value
|
In doctrine/collections#389, I introduced a new enum:
Order
What should we use it for inside the ORM?
OrderBy
attribute: this is a clear use case where we should switch to that enum, since it has to do with collectionsQueryBuilder::orderBy() / addOrderBy()
: this one is less clear to me… when you select several entities, you don't get a collection, but a list, right?Expr\OrderBy
: I'm not sure we should do it here either.@derrabus @SenseException any thoughts?
Cc @ThomasLandauer
The text was updated successfully, but these errors were encountered: