`INSTANCE OF` support in Criteria API Expressions

[skornev]

You can you use "Instance" of in DQL and QB. Maybe I missed something but it looks like there is no way to use it in Expression?

[Ocramius]

@skornev ->andWhere('a INSTANCEOF B')

[skornev]

It does not work.

An exception has been thrown during the rendering of a template ("Catchable Fatal Error: Argument 1 passed to Doctrine\Common\Collections\Criteria::andWhere() must implement interface Doctrine\Common\Collections\Expr\Expression, string given

[skornev]

I want to use Criteria::create() ->where(Criteria::expr()->eq("isFolder", "1"))->andWhere('a INSTANCEOF OF B)

[Ocramius]

Ah, I thought this was about DQL only (and the DQL expression builder), not about the criteria API, sorry. Re-opening and renaming issue.

[SInCE]

+1 for an instanceOf() Expression in the Criteria API.

[JeromeGill]

Yes please!

[massimilianobraglia]

it would be awesome!

[greydnls]

:+1: Yes please.

[imunhatep]

+1

[jonbev]

+1

[martinsifra]

+1

[dc-dstepanov]

+1

[trickeyone]

+1 Definitely! 👍

[tvequaud]

+1 (and nothing since june 2016 ???)

[Ocramius]

Yep, nothing since then.

On 7 Mar 2017 3:47 a.m., "Thomas Véquaud" notifications@github.com wrote:

+1 (and nothing since june 2016 ???)

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/doctrine/doctrine2/issues/5908#issuecomment-284658480, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJakI22Iz3iMJ8l89l47GUewz8OAC47ks5rjRmYgaJpZM4JCJiN .

[pixels-farm]

So sad....

[courtney-miles]

+1

[theofidry]

The interested has been clearly shown already so stop +1 and do a PR if you're interested...

[courtney-miles]

so stop +1

Apologies -- my +1 was not intended to aggravate anyone.

Some projects embrace +1 as a way to gauge interest in features in the absence of voting.

[imunhatep]

@theofidry I made a brief research on this issue. "INSTANCE OF" expression is based on Entity annotations and QueryBuilder, which resolves expressions to DQL. But Criteria expressions resolved to raw SQL. As I understand, Criteria expression resolver (BAsicEntityPersister) should be rewritten to use QueryBuilder. That would be a huge PR and I doubt that it will pass CR by Doctrine team.

[theofidry]

@Imunhatep thanks for looking into it. I guess then it's up to the core team to determine if this can be done in 3.x in which case it can be added to the 3.0 milestone or if this feature won't be implemented

[imunhatep]

I were thinking a little bit on this problem and probably i was wrong. There is no need to rewite Context expression resolver to use QueryBuilder it would be overkill. A simplier approach would be just add a similar logic for resolving INSTANCE OF expression from QueryBuilder to Context expression resolver. Or to not duplicate business logic.. Move INSTANCE OF expression resolving logic to a separate handler. And add filtering for collections. It's still not an easy task.. But at least possible.

[spackmat]

Hey, two years have gone since the last post. Any news about this issue?

I stumbled upon the same problem as described in https://github.com/doctrine/collections/issues/113 and didn't find another smart solution: Cannot use the discriminator column directly ("Unrecognized field"), cannot use the specific properties of the subclasses ("Unrecognized field" as they are ManyToOne-relations which isn't supported by the Criteria), cannot use instanceOf, cannot hydrate the whole Collection to filter it (it can be very huge in my case as it is an activity log).

How did others solve that? For now I avoid the Collection and have a repository method to get the count of log entries of a specific type. This is suboptimal, because all my other entities can handle their isDeletable() state on their own counting their restricting relations.

[trickeyone]

@spackmat Unfortunately, v1.5 implemented strict checking which makes my solution from #113 not work any longer. I submitted #168 which has been added to 2.0 milestone. Hopefully we'll get a fix soon. For my projects, I've had to lock them at 1.4 to keep this functionality.

[spackmat]

I did a dirty workaround in my case, since I only wanted to enable a user to be deleted, if it only has activities editing a User entity (itself in most cases) and preventing deletion if it has activities of any other type. So when there are less than 20 activities, I hydrate them all with a filter() and when there are 20 or more, I assume that there will be at least one of another type and the user cannot be deleted. So if one creates a new user, logs in as this user and edits this user 20 times, it is incorrectly considered undeletable and thus can only be hidden. I can live with that.

[SenseException]

Of course Pull Requests are always welcome and your time and effort is appreciated.