Closed (fixed)
Project:
Drupal core
Version:
8.0.x-dev
Component:
database system
Priority:
Normal
Category:
Task
Assigned:
Issue tags:
Reporter:
Created:
12 Feb 2014 at 21:54 UTC
Updated:
29 Jul 2014 at 23:22 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
sunComment #2
jibransimple enough.
Comment #3
Crell commentedThe typical case for a merge query is a single-value key; multi-value keys are not common IME. That's why it was called key() originally. If we do this, I would not mark key() deprecated. Just call it an alias and be done with it.
Comment #4
sunHappy to do so :-)
That said, given the explanation for why the method is using a singular name (thanks!), I wondered whether this split here wouldn't actually allow us to give
key()a signature that corresponds to its intended use-case?Like this:
Might be worth as a follow-up issue?
Comment #5
Crell commentedGood idea. Let's go ahead and do that now. So keys() takes a single associative array, key() takes a singluar key and value. That's more descriptive and non-redundant. And I think not even an API change. :-)
Comment #6
sunMerge::key(), but retaining a BC shim.keys(array)orkey(field, value).Comment #9
sunReverted change to invocation order in Cache\DatabaseBackend.
This should come back green again now.
Comment #10
sunDraft change notice: https://drupal.org/node/2205327
Comment #11
sun9: merge.keys_.9.patch queued for re-testing.
Comment #12
Crell commentedDone and done. Thanks, sun.
Comment #13
dries commentedNice little API improvement. Committed to 8.x.