This patch allows explicit inheritance in site aliases.
If you have an alias for a server, like so:
$aliases['myserver'] = array(
'remote-host' => 'myserver.domain.com',
'remote-user' => 'publisher',
);
And another alias for a dev site, like so:
$aliases['mysitedev'] = array (
'uri' => 'http://mysite.org',
'root' => '/srv/www/drupal',
);
Then you can make an alias for a live site that merges the two records together using multiple inheritance like so:
$aliases['mysitelive'] = array (
'parent' => '@myserver,@mysitedev',
);
Of course there are also many other variations. You may have one alias that defines your Drupal root, and use single inheritance to define each multisite at that root as a separate alias that inherits from the root alias. If a child alias defines values that are also defined in the parent, then the values from the child will take priority.
Note that this implementation does not guard against circular 'parent' references. Drush will fall into an infinite loop if alias A inherits from B inherits from C inherits from A. This degenerate situation could be guarded against by caching the alias record before and after checking for inherited values; however, this fix would have a performance cost (probably slight) whether or not inheritance is used. Let me know if you want the guard, which would essentially involve calling drush_set_config_special_contexts twice (but it's a little more involved than that, since that function modifies its inputs).
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | inheritance-for-aliases-3.patch | 12.73 KB | greg.1.anderson |
| #1 | inheritance-for-aliases-2.patch | 6.01 KB | greg.1.anderson |
Comments
Comment #1
greg.1.anderson commentedSame patch as above, but with efficient circular-loop prevention. There should never be circular references in inherited values, but it's helpful to have drush not crash if it happens.
This patch also fixes a bug in the above; the array_merge parameters were backwards, causing the parent values to override the child values rather than the other way around.
Comment #2
adrian commentedjesus greg! you are a machine , you know that =)
will review this shortly.
Comment #3
greg.1.anderson commentedWhy thank you; very kind of you to say so. Now that the code is cleaned up a bit, these minor features are falling out pretty easily.
Along those lines, I stayed up late last night and reworked the site alias documentation. When I did, I realized that site-specific aliases were a little bit awkward to use in some instances -- e.g.
drush demosite.drupal6.local site-alias --full @peer. It would be a little more straightforward in these instances to use relative aliases, a-la your suggestion from last week.Relative aliases fall out pretty easily from alias inheritance. This version of the patch allows the previous example to instead be expressed as
drush site-alias --full demosite.drupal6.local/@peer. That's not really shorter than the alternative, but it is more straightforward and clear. Of course,@mydevsite/@peeralso works.Comment #4
moshe weitzman commentedSeems like adrian has gone missing for a bit. Lets go ahead with this. He can provide feedback after commit too.
Please do update the handbook docs and example.aliases.drushrc.php as needed
Comment #5
adrian commentedi liked this patch , my only concern is the following :
if i write a command to load and save these record files, when i write out to the file, all the options set in the parents will get cached to the file as well.
What I need is basically a parameter on the 'load_alias' function, that stops the cascading from happening, so that i can easily write just the relevant options to the configuration file.
Comment #6
greg.1.anderson commentedGood suggestion. I've been busy the last few days; will try to find a good solution for this soon. I do want the options set from the parents to go into the cache; otherwise it complicates the most-common case too much. I'll try to make you a lower-level function to call to get just the raw alias definition without hitting the cache.
Comment #7
adrian commentedusing them merged in memory makes sense, the only place this becomes an issue is when you need to save to files.
Comment #8
greg.1.anderson commentedI refactored #3 slightly so that you may now call
_drush_sitealias_find_and_load_alias($aliasname)to get the raw alias record, without the 'parent' record being processed. Note that because this is a low-level command, $aliasname should not begin with an "@". Relative aliases in $aliasname are not supported, but you can access relative aliases with this routine if you pass in an alias record (obtained viadrush_sitealias_get_record("@alias")as the optional second parameter to _drush_sitealias_find_and_load_alias.Committed with updated docs.