Problem
Merge::key()accepts an associative array possibly containing multiple values.Merge::fields(),Merge::values(), etc are all plural.- But yet,
Merge::key()is singular.
Proposed solution
- Rename the method into
Merge::keys(), but provide a backwards-compatible aliasMerge::key().
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | interdiff.txt | 1.01 KB | sun |
| #9 | merge.keys_.9.patch | 20.18 KB | sun |
| #6 | interdiff.txt | 20.21 KB | sun |
| #6 | merge.keys_.6.patch | 20.31 KB | sun |
| #4 | drupal8.db-merge-key.4.patch | 1.03 KB | sun |
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.