-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
ArrayCollection->matching() not working anymore with Criteria->eq('id', $number) #9109
Comments
Someone commented here and removed the comment again (probably because it did not work for them neither), but I still tried the idea. The idea was to remove the vendor folder and re-install with composer again: it did not work here. Thanks for the idea, though! |
@greg0ire @Tagirijus isn't this fixed? |
As I wrote: "it persist in v2.10.1". (-; |
Hello, I tried a reproducer (in a symfony app, but still): https://gist.github.com/Nek-/b799f16acc1ff73833dd2f2a1d634848 It's working fine with Doctrine ORM 2.10.2. |
@Nek- Hi mate! Is your gist missing a EDIT: ah no, it's just missing a And then the patch cannot be applied, because of how fast the ecosystem evolves: patching composer.lock won't work I'm afraid :p |
Fixed, nvm it just exposes that it's working fine and this issue should be closed to me 😉 . |
Well, sorry but it does still persist in v2.10.2 here. I also removed the vendor folder and did Edit: when I find some time, maybe I can dig deeper into this and try to understand on how to make some tests, in case my code example in my intitial post does not help. Sorry for not being able to give more information right now. One information I found out, while I am not sure, if it is important: when downgrading again to work in v2.9.5 (since it works here), composer also shows that it is downgrading doctrine/dbal v3.1.3 to v2.13.4 and removes symfony/polyfill-php72 v1.23.0. Oh an another info: I do not work with symfony at all. I use Siler as a framework underneath ( https://github.com/leocavalcante/siler ). |
@Tagirijus please provide a reproducer. I took some personal time to try to reproduce and fix your issue but instead I ended up showing that it's working fine. |
I am using DoctrineOrmModule, running composer update doesn’t solve the problem |
@Nek- @greg0ire @Tagirijus It should be here: https://github.com/doctrine/orm/blob/2.10.x/lib/Doctrine/ORM/Persisters/Collection/ManyToManyPersister.php#L252 to contextualize, this happens before the bug:
so here is the problem:
$field needs to be replaced with $name
Test results after that change:
pay attention to merge with "weak" tests involving this: #9010 |
@armenio without making a testcase to reproduce, can't you reproduce your issue in a standard app? (no matter the framework, just use yours to be the closest possible to your case). |
…h Criteria->eq('id', $number)
can you reopen? |
It would be okay to me, if this one only gets re-opened, when I finally come up with some clear reproducible tests, hehe. I do not find time for this at the moment, though. Sorry. ))= |
Could not test this either. But still thanks for your effort! (= |
what can i do to help even more? |
Get me some more free time so that I finally could test your posted test case on my own, haha. :D (-; |
@armenio assuming this used to work in the past, you could use |
@greg0ire I found!
|
Next steps:
|
Oh wow hold on a minute… do you mean to say you would have spotted the issue had you reviewed that PR? |
Maybe, why not? I did this to get your attention that there really is something wrong there. |
What would be the point? You've demonstrated that I'm not good enough to review a PR. |
Please don't get me wrong. maybe it's because of my bad English. See the quotes in the word. |
Not super convincing, but in doubt, I'll accept the apology and give this PR a review. |
Infer type from field instead of column getTypeOfColumn() relies on getTypeOfField(), and does not suffer from mismatching issues caused by quoting, because you cannot quote a field. Since a field can be composite, that method returns an array, hence why we need to select the first element. Fixes doctrine#9109
getTypeOfColumn() relies on getTypeOfField(), and does not suffer from mismatching issues caused by quoting, because you cannot quote a field. Since a field can be composite, that method returns an array, hence why we need to select the first element. Fixes doctrine#9109
Bug Report
Summary
It seems that something changed with the
->matching()
method of an ArrayCollection. It persist in v2.10.1.Current behavior
When I have an ArrayCollection I want to filter with
matching
and a Criteria, which has an expression like->eq('id', $number)
my script tells me something like:"Could not resolve type of column "`id`" of class ..." and so on.
How to reproduce
Let's say you have an entity "work" with an ArrayCollection called "connectedalbums", which stores other entities like "album". I now want to access the album with the id "3" and would do it like this:
With this, PHP throws an Uncaught RuntimeException like mentioned above.
Expected behavior
I expect an ArrayCollection with
->matching()
and the Criteria with the expression->eq('id', $number)
to give me the correct item from the ArrayCollection, whichs column id has the value, which is stored in $number. It worked like this in v2.9.5!The text was updated successfully, but these errors were encountered: