Archives with no-core and possibly only-platform

Posted by helmo on September 16, 2011 at 1:25pm

I've been working on a --no-core option in my sandbox (http://drupalcode.org/sandbox/helmo/1277350.git)

For archive restore to handle this we need some info in the manifest file indicating this.

In the issue below I've suggested a 'dump_type' field being either site or platform. But maybe we can think of something better...

1280218: archive-restore adaptation for an archive made with --no-core option - http://drupal.org/node/1280218

Comments

@helmo - could you please

Posted by moshe weitzman on October 20, 2011 at 12:26am

@helmo - could you please provide an example here of the proposed enhancement to site archive format. i don't think many folks will chase down the code in your sandbox to figure out what you propose.

The Global section would,

Posted by helmo on October 21, 2011 at 10:00am

The Global section would, with my patch, look like:

[Global]
datestamp = "1319190712"
formatversion = "1.0"
generator = "Drush archive-dump"
generatorversion = "5.0-dev"
dump_type = "platform"

And with --no-core result in:

[Global]
datestamp = "1319191126"
formatversion = "1.0"
generator = "Drush archive-dump"
generatorversion = "5.0-dev"
dump_type = "site"

The changes from my sandbox are now available as a patch in http://drupal.org/node/1277484#comment-5144024

Seems reasonable to me. I

Posted by moshe weitzman on October 25, 2011 at 3:23pm

Seems reasonable to me. I like 'site' and 'platform' as values. If unspecified, we continue to assume platform (which means that drupal core is included).

I'm not wild about 'dump_type' as a key but I can't think of a better alternative.

I'm not wild about the name 'dump_type' either

Posted by helmo on November 3, 2011 at 1:11pm

I'm not wild about the name 'dump_type' either, but I was lacking an alternative.

What about:

archive_content_type
archive_format_type
formattype

how about just

Posted by moshe weitzman on November 3, 2011 at 1:24pm

how about just archive_format?

Sounds good, I've renamed it

Posted by helmo on November 8, 2011 at 10:28am

Sounds good, I've renamed it in my sandbox.

http://drupalcode.org/sandbox/helmo/1277350.git/commitdiff/master-upstre...

I know I'm coming a little

Posted by ronan on November 10, 2012 at 3:20am

I know I'm coming a little late to this conversation (1 year and 1 day late in fact) but I am only now getting around to rolling out the next version of Backup and Migrate and am going to make the site archive format a core part of how it works.

I like this specification but have 2 suggestions:

1) Adding another 3 types:
- database: Just the db dump and the metadata
- files: Just the site's files and metadata
- userdata: DB and files but no code
Not sure that the first 2 are necessary except for the sake of completion. From a backup perspective there is value on bundling the files and DB without the code (since that's often version controlled and deployed in a different manner).

2) This is very minor, but all of the other agreed upon metadata names are glued together without punctuation or use a '-' for separation. The underscore in archive_format is sticking out like a sore thumb to me. I would prefer 'archiveformat' or 'archivetype' for consistency.

We're gonna have more stuff

Posted by moshe weitzman on November 11, 2012 at 2:29am

We're gonna have more stuff in Drupal 8. Namely, there is Config, Key/Value store, Entity storage. Not sure if those merit inclusion as well. Lets discuss and then we I'll implement whatever we decide in Drush as well.

I don't understand any of

Posted by ronan on November 12, 2012 at 4:41pm

I don't understand any of that last bit because I'm pretty far removed mentally from what's going on in 8. I assume that is non-db ways of storing config, and that the proposal is to store some of that in the site archive. Is that right?

Either way, I'll happily follow the lead of Drush (which is way ahead of B&M in terms of dev cycle).