Document that db_like() and Database/Connection::escapeLike() do not work when used with db_query()

That's probably because the ESCAPE clause is missing from your second query.

But given the amount of heavy-lifting required to make LIKE work consistently across database engines, I would recommend sticking with db_select() and considering that LIKE is not supported in db_query().

Have I mentioned how much I hate SQL databases?

This needed a re-roll for /core, but I just did a cd /core before applying and it still applied with that fortunately.

Seems like we need to backport this to 7.x too, patch here might apply so leaving CNR.

It may be because of the "For example" but I think the documentation would flow better if the new note was after the example instead of before it. The for example references the paragraph describing how to use it, not the noted caveat about its usage we're adding.

#5: 1182428-dblike-does-not-in-fact-like-dbquery.patch queued for re-testing.

I think this was supposed to be applied to D8 3 years ago, but somehow wasn't.

This is already fix in Drupal 8.2.x.

This looks like it's in Drupal 8 at https://api.drupal.org/api/drupal/core%21includes%21database.inc/functio... but that function is marked deprecated in favor of https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Database%... and that one does not document this at all. So I think it just needs to be copied to the new function also.

(Although as part of copying it, the code example probably should be rewritten to actually use escapeLike() rather than db_like()... the current example on escapeLike() actually uses db_like() instead which doesn't make much sense.)

Plus, this issue originally had the backport tag and isn't fixed in Drupal 7 yet.

@David: I did not thought about Connection::escapeLike(). Good thinking on your part! I made three options for escapeLike. A short , medium and long version. Which do you like. My preference is the medium one.

The short version is closest, but we shouldn't be recommending/encouraging the use of the global statics, ever. Just use $connection, people will figure out they need to get it from somewhere.

+   * You must use a query builder like ->select() in order to use ->escapeLike() on
...
+   * You must use a query builder like Database::getConnection()->select() in
...
+   * You must use a query builder like
+   * Drupal\Core\Database::getConnection()->select() in

Technically according to https://www.drupal.org/coding-standards/docs#classes documentation is supposed to use the fully-qualified namespace, so actually none of the above are quite right... it should be something like \Drupal\Core\Database\Connection::select() instead.

(Most important, though, is to make sure it uses something that api.drupal.org can figure out how to link to, so it's clickable when someone reads this on api.drupal.org. The fully-qualified namespace presumably meets that criterion; not sure offhand if anything else does.)

Actually I guess the coding standards don't quite say you have to use a fully-qualified namespace (just that if you do use one, it should be fully-qualified). Key point is still that it should be clickable on api.drupal.org though... I don't think ->select() would be (but Connection::select() might?).

I did a combination of \Drupal\Core\Database\Connection::query and $connection->query() or $connection::query() in the hope that people more easily will figure out what the variable $connection means. Which version do you think is better?

I think it probably should be the opposite actually (\Drupal\Core\Database\Connection::query() in the paragraph so that api.drupal.org will turn those into clickable links, then $connection->query() in the code example since that's what actual code will look like)?

The code example also still needs to be updated to change db_like() to $connection->escapeLike().

The automatic linking to api.drupal.org is important, but it reduces the readability of the added documentation a lot. So two new versions.

1. +++ b/core/lib/Drupal/Core/Database/Connection.php
   @@ -987,12 +987,20 @@ public function escapeAlias($field) {
   +   * order to use \Drupal\Core\Database\Connection::escapeLike() on all
   +   * supported database systems. Using
   

   "on all supported database systems" isn't that implied by them implementing the interface. Additionally is it even something we can claim since a database could implement the method with trigger_error() and not support it if they wanted.

2. +++ b/core/lib/Drupal/Core/Database/Connection.php
   @@ -987,12 +987,20 @@ public function escapeAlias($field) {
   +   * Drupal\Core\Database\Connection::escapeLike() with
   +   * Drupal\Core\Database\Connection::query() or
   +   * Drupal\Core\Database\Connection::queryRange() is not supported.
   

   These still don't have the leading \

@neclimdul: Good points.

Maybe I'm misreading, but doesn't the text now say "you can't use query() with escapeLike()", and then show an example that's based on query()?

@Crell: You are right. Fixed it.

Thank you helpful merge commits for reminding us all this exists. Looks commitable to me. Good solid docs fixes.

This needs a new issue for the documentation follow-up, and a new issue for the 7.x backport. Moving back to fixed since the original patch was committed in 2011. Please link to the new issues from here if you open them.

@catch: I agree with you that there needs to be a new issue. But marking this one as fixed and a automatic closed after 2 weeks makes this issue disappear. And the follow up work that is in this issue with it. Not happy about it. I created a follow up in #2786811: Document that Database/Connection::escapeLike() does not work when used with Database/Connection::query() and Database/Connection::queryRange().

@daffie if you look at #10 the follow-up work was already lost for three years because the issue was against the 7.x branch at CNR - it's the re-opening issues for minor changes that causes work to get lost in the cracks, not asking for proper follow-ups to be opened.