Several related problems:
a. we want our development site to connect to a development service, rather than the one with the live data.
b. we want the login credentials to the live service to NOT be in the codebase in Features, as not all developers with access to the codebase are to be granted access to use the live service's data
c. we want a staging server that DOES connect to the live service, but can only read to it, not write to it
Obviously, a. could be done simply with multiple connections, but then every part of the code that loads a connection to do something with it needs to be environment-aware. It would be simpler to have the switch happen in one place only.
b. suggests that we should move username and password to be stored in a separate table from the entity table, so they are database storage only and not in the exportable connection.
For c, it's probably up to each connection type to define things which are 'write' calls.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | 1998078.clients.connection-substitution.patch | 9.22 KB | joachim |
Comments
Comment #1
joachim commentedThing is, the only things in common would be the connection type and machine name. And as we're using the machine name as the exportable key, that can't be duplicated.
Comment #2
joachim commentedb. is probably something separate -- a credentials plugin system, where each plugin chooses where and how to store its data (so for ease of use, and for dev connections, or those where security is less important, we could have one that works like the current system and stores in the connection configuration).
For a & c, I see two fundamentally different approaches:
- split the connection handler up, giving it sub-connections per environment. The connection load API then selects the right sub-connection.
- add 'related' connections, perhaps with a machine name suffix, or an environment property. The connection load API then selects the right suffix to add to the machine name when loading a connection.
Comment #3
joachim commented> - split the connection handler up, giving it sub-connections per environment. The connection load API then selects the right sub-connection.
This is probably the cleanest conceptually. But it would be a huge architectural shift to go to having a set of sub-connections within a connection. The exportables system would need a complete rethink.
> - add 'related' connections, perhaps with a machine name suffix, or an environment property. The connection load API then selects the right suffix to add to the machine name when loading a connection.
This is much easier to add on to the system there already is.
Comment #4
joachim commentedComment #5
joachim commentedChange record: http://drupal.org/node/2002698