in the review comments by webchick over in #1697256-73: Create a UI for importing new configuration, it became clear that we need a way to handle cases where site builders may overwrite the active config directory with changes without going through the import step.

currently, we have no good way to warn or back out of this process. lets figure that out here.

#2 1821306-2-config-snapshot.patch2.21 KBbeejeebus
FAILED: [[SimpleTest]]: [MySQL] 46,128 pass(es), 1 fail(s), and 205 exception(s). View
Members fund testing for the Drupal project. Drupal Association Learn more


beejeebus’s picture

so it turns out if we want to make a hash of config files for backup, then we should prolly pass them through config() when we install / import them. else we need to make the storage controller smart, which is prolly Not The Right Way.

i just hacked up a quick PoC patch, and noticed that we're missing a whole bunch of snapshots, because when we install, we just operate directly with the storage controllers.

why do we do that again, rather than use config('foo')->save() ? i can't remember.

beejeebus’s picture

Status: Active » Needs review
2.21 KB
FAILED: [[SimpleTest]]: [MySQL] 46,128 pass(es), 1 fail(s), and 205 exception(s). View

so here's a PoC that creates snapshots. note that i had to change the way we do config sync stuff to use config->save() etc.

Status: Needs review » Needs work

The last submitted patch, 1821306-2-config-snapshot.patch, failed testing.

damiankloip’s picture

Issue tags: +VDC

Tagging, as this could be what we were thinking of trying to do for views/config anyway.

beejeebus’s picture

not working on this anymore, please don't wait for me.

sun’s picture

Priority: Major » Normal

Meanwhile, I think we should simply revert the default storage for active config back to the database (or any other k/v storage).

Allow informed developers to override that default and use files instead, but don't make it the default.

moshe weitzman’s picture

I like that Active uses filesystem. This is most transparent and learnable to people. It also lets them use diff, git, and other filesystem tools. IMO, the fact that some folks are uninformed or reckless does not justify "hiding" this data in k/v or DB.

moshe weitzman’s picture

These directories have README files that can explain how to behave there. I think thats sufficient.

alexpott’s picture

Status: Needs work » Closed (won't fix)

Based on #8 this is won't fix. If someone deletes or edits their db - they better have a back up - this is no different.