Allow EntityQuery to be converted to the underlying SQL query

The Needs Review Queue Bot → tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Rebased to 10.1.

Failures in MR 3446

Should be simple think they're now missing accessCheck()

Thanks!

::toSqlQuery() is a new API added which is great! But I think a CR is required. 🐛 ContentEntity migration source doesn't consider the migration map Needs work demonstrated its usage. The CR could probably mention it.

Thanks!

We're in a bit of a grey area as to how much of an API this is, as EntityQuery can take different backends.

What does it mean for a non-SQL backend to convert the query to SQL?

I think this needs input from a maintainer.

When I read the issue title, I thought this was for debugging like getting the string SQL query easily, which sounds handy.

But it's not really for debugging, it's more of an actual API to convert to a select query, and I... don't know what I think about that.

Yes, also pretty much a -1 on this, and I suggested a different approach for 🐛 ContentEntity migration source doesn't consider the migration map Needs work to @joachim.

The abstraction from SQL is by design, it's supposed to be used also for a different storage. The tag-based approach gives different implentations at least a chance to do something similar. A toSql() does not.

Moving to NW as that seems to be 2 of the Entity API not sold on this. Is there a tweak that can be made to pass this?

> When I read the issue title, I thought this was for debugging like getting the string SQL query easily, which sounds handy.

I think we should repurpose this to use for debugging only, given #20.