Postponed (maintainer needs more info)
Project:
Drupal core
Version:
main
Component:
other
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
3 Aug 2014 at 06:44 UTC
Updated:
14 Feb 2026 at 19:47 UTC
Jump to comment: Most recent
Comments
Comment #1
dawehnerOne question. If you look at the default implementation for a database you see the following functions:
I wonder whether we could generalize here to make the UI usable for every storage backend?
Comment #2
chx commentedThat stuff is off topic I am afraid: there are a number of whacky methods on this class which aren't on the interface. I wonder whether there is an issue for that already or we need to file another one.
However, what's on topic is whether we need to make this more generic: everything we mark with the new backend tag should have one of these. In a perfect, Drupal 5.5 world it would not be an iterator but a Generator so that you can use it for read-write. Lacking that, I wonder whether we could add a writeFromIterator method to all backends accepting an iterator. The primary use case here is switching backends. This way the handover would look like this:
Handy.
Comment #3
chx commentedComment #4
chx commentedComment #5
Crell commentedchx and I discussed this at length in IRC and came up with the proposal in the summary now. +1 to it.
(This means not all services are necessarily transferrable. So be it. It's up to the person defining the interface for the service to decide if it makes sense to do.)
Although that's an interesting question: Should the service interface implement this new TransferrableServiceInterface, or should individual service implementations do so? (Meaning that you could have a case where you can transfer into but not out of or out of but not into a given service backend implementation.)
Comment #6
chx commentedGiven that #2161643: Add a KeyValueStore\IterableKeysInterface (allowing to retrieve keys with a given prefix) iteration is doable in practically any backend I would say it's the interface but I think we could be a bit flexible here and put it on the interface when that makes sense (config listAll already requires an iterable store) and on the implementation when that makes sense (keyvalue).
Comment #7
chx commentedComment #21
smustgrave commentedThank you for creating this issue to improve Drupal.
We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.
Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.
Thanks!
Comment #22
smustgrave commentedWanted to bump this 1 more time before closing.
Comment #24
smustgrave commented