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

  1. Create an interface with a getTransferIterator method on it.
  2. Make backends implement it. Good thing PDO returns iterators...
  3. Every backend service should have a .transfer suffixed transfer service.

Remaining tasks

Code this.

User interface changes

API changes

CommentFileSizeAuthor
path_iterator.patch1.45 KBchx
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 75,016 pass(es). View
Members fund testing for the Drupal project. Drupal Association Learn more

Comments

dawehner’s picture

One question. If you look at the default implementation for a database you see the following functions:

public function getAliasesForAdminListing($header, $keys = NULL) {

I wonder whether we could generalize here to make the UI usable for every storage backend?

chx’s picture

That 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:

$destination->writeFromIterator($source->getIterator()).

Handy.

chx’s picture

Title: Make it possible to find all paths on the site » Make it possible to find all path aliases on the site
chx’s picture

Title: Make it possible to find all path aliases on the site » Make it possible to transfer contents of backend services
Component: path.module » other
Issue summary: View changes
Status: Needs review » Active
Crell’s picture

chx 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.)

chx’s picture

Given 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).

chx’s picture

Assigned: Unassigned » chx

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.