Allow using a separate db connection for Admin

[elidrissidev]

Description (*)

This PR adds a new feature that allows optionally using separate database connections (admin_read and admin_write) for the Admin store. This can be desired for many reasons such as limiting the privileges of the frontend connection's db user. By default, these connections inherit the default ones, so they should work out of the box without any configuration.

Fixed Issues (if relevant)

1. Fixes Separate admin and front-end database users for monitoring and security #2870

Manual testing scenarios (*)

1. Go to your local.xml and add the following configuration inside config/global/resources element:

<admin_setup>
    <connection>
        <host><![CDATA[localhost]]></host>
        <username><![CDATA[root]]></username>
        <password><![CDATA[root]]></password>
        <dbname><![CDATA[openmage]]></dbname>
        <initStatements><![CDATA[SET NAMES utf8]]></initStatements>
        <model><![CDATA[mysql4]]></model>
        <type><![CDATA[pdo_mysql]]></type>
        <pdoType><![CDATA[]]></pdoType>
        <active>1</active>
    </connection>
</admin_setup>
<admin_write>
    <connection>
        <use>admin_setup</use>
    </connection>
</admin_write>
<admin_read>
    <connection>
        <use>admin_setup</use>
    </connection>
</admin_read>
<!-- 
It's important to override core_setup to use the new admin connection 
for setup scripts to run without problems, especially if you limit the privileges
of default connection.
-->
<core_setup>
    <connection>
        <use>admin_setup</use>
    </connection>
</core_setup>

Test to make sure the Admin area is now using the new connection. In my case, I made it use the database with sample data installed, whereas the frontend was using a clean database.

Contribution checklist (*)

• Pull request has a meaningful description of its purpose
• All commits are accompanied by meaningful commit messages
• All automated tests passed successfully (all builds are green)
• Add yourself to contributors list

[sreichel]

Nice,

We should ...

• add some info to README
• update local.xml.template?
• add PR for DDEV

[sreichel]

Seems not to be a BC break. Change branch?

[Flyingmana]

This way the same function can for the same input return a different connection. If you send an email, the store is changed via emulation, probably not beeing Admin anymore? which means that existing transactions are ignored (or changed data from them not available) and, simply said a lot of hard to debug problems

[Flyingmana]

If you need a separate connection for admin, than it makes more sense to use a different Config for the whole request.
There was a Feature planned, to provide local.xml configs via Environment Variables, which means you could configure on the webserver level to use a different connection for Admin, which would achieve the same, with less potential for hard to debug Bugs.

[elidrissidev]

I will check the env variables solution later. For now this is going back to draft.

[sreichel]

There was a Feature planned, to provide local.xml configs via Environment Variables,

Do you have link for that?

[elidrissidev]

Do you have link for that?

I think this: #643

[Flyingmana]

Do you have link for that?

I think this: #643

yes, this was the one I had in mind, was not able to find it anymore

[fballiano]

I like this solution more compared to #643, could it be possible to fix the emulation?

[elidrissidev]

I like this solution more compared to #643, could it be possible to fix the emulation?

I don't know yet, haven't much time to explore this further.

[Flyingmana]

When following the way with having a separate connection during the request, you probably need to introduce a state, (which increases the complexity of the class).
Maybe it also needs to be checked, how it reacts for cronjobs, Iam not sure if they use the admin or default store in the beginning. But I have seen some which change the current store.
When doing so, keep also the cleanup in mind, as some setups depend on \Mage::reset() to work properly, as they process multiple requests without bootstrapping a new request/process.

Also it might make sense to make this configurable and default Off, as its going to double the parallel connections to the database, which might break a lot of closely optimized Setups.