Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
Problem/Motivation
I am trying to switch path storage backends. This is impossible as there is no way to figure out what the backend contains.
Proposed resolution
This actually is a special case which could be extended to every backend as defined in #2302617: Define a standard mechaism for backend-aware service overrides and tagged in #2306071: Tag backend services. . The proposal is to
- Create an interface with a
getTransferIterator
method on it. - Make backends implement it. Good thing PDO returns iterators...
- Every backend service should have a .transfer suffixed transfer service.
Remaining tasks
Code this.
User interface changes
API changes
Comment | File | Size | Author |
---|---|---|---|
path_iterator.patch | 1.45 KB | chx | |
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 CreditAttribution: 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 CreditAttribution: chx commentedComment #4
chx CreditAttribution: chx commentedComment #5
Crell CreditAttribution: 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 CreditAttribution: 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 CreditAttribution: chx commented