Working with multiple developers in the same environment

[brendo]

Hey Remie,

We're in a situation where we have multiple developers working on a single Symphony instance that all have CDI set to be a slave instance. The problem is that as the queries are written to the file (and a single line at that), Git often has conflicts when we merge the database changes around.

@nickdunn pointed me to your logquery-db branch, so just wondering if that's an idea or actually the future moving forward?

[nickdunn]

Future! Future! I hope.

Early versions of DB_Sync wrote to a database and it worked well in a multi-developer setup (we had 5 devs connecting to the same local database server in the office). But then there was an urgent bug (reported by Rowan?) where my logging inserts were interfering with Symphony's own auto-increment IDs. So I changed it to log to files. Boo.

But I think Remie worked around this. So fingers crossed.

[remie]

Well... there should be a single master instance which saves the changes to file. This file can be committed to GIT. The Slave instances should do an pull of the latest log file and run the update script. The update script reads the log file and compares them with the change log in the local database (cdi_log table).

This setup should not be causing any merge conflicts because there should be no changes to the log file made by the slave instances.

So either this is a genuine bug, because CDI slave instances are writing to the log file (which they should not do), or the setup is incorrect (I hope it is the latter) :)

[remie]

where my logging inserts were interfering with Symphony's own auto-increment IDs

This is indeed fixed, and will be even easier to use with the query delegates (no need to change core files).
However, CDI will still use a log file on the master database because it needs to propagate the changes to the slave instances. This is currently done using a file which can be transfered to the slave instance and which is used by the update script.

The future is more bright: the query delegates will allow me to implement active syncing of slave instances (replication)m but this is scheduled for 2.0.0 (no delivery date set)

[brendo]

Ah ok. With our setup the config.php file is shared between developers so all CDI instances will be set as Masters (to capture each developers work) and the Slave is the live site.

[remie]

Haha, yes, that can be a problem. The design does not support multiple master instances.
The reason is that it is almost impossible to ensure structure integrity if you have multiple master instances: what if two developers perform the same structural change? At best this would cause the Slave update script to fail, worst case it would corrupt the database on the Slave instance.

The feature should be easy to implement though by adding a unique identifier to the query log entries. This would solve your merge problems. My suggestion would be that you leave structural change to the team lead (Master) and have the other developers run CDI in Slave mode.

[jonmifsud]

By any chance were there any updates / alternative plans for this?

We've just set up git and want to give this extension a try... even if where possible we assign developers to tasks sometimes they are moved around projects, and priority projects are at times assigned to more then a single developer.

Something like two+ users running master but having to 'sync' their DB when one makes any structural change would do. As long as it doesn't require them to every time remember to change their mode master / slave as I guess one has to do right now if they want to run updates.

[remie]

@jonmifsud: I'm sorry to say that implementing this is rather difficult :(

An alternative approach would be to setup a development environment that is on a remote server. In case of the need for structural changes, this should be done on the development server. That way the developers will always be in Slave mode, they don't have to change. However, they do need to remember not to make any structural changes on their local database.

I'll be on vacation until august but I will be picking up this task after I return!

[jonmifsud]

Hmm no worries - we do have a shared 'dev' setup however its meant to pull changes from git.. not sure if creating pages on it could have any repercussions. (sync wise) So I guess will try stick to the developers changing their mode when they need to do structural changes (at least for-now), and switch back to slave to ensure that when they commit the other machines are all on slave mode. Will see how it goes

Enjoy your Vacation!

[nickdunn]

This is what we used to do. All devs work locally (files) but connect
to a shared database (in an office this is quick over local network!).
The dev web server pulls from git and also uses the db. Nobody logs
in to Symphony on dev ever, since any file changes get killed.

On 17 Jul 2012, at 07:58, Jonathan Mifsud
reply@reply.github.com
wrote:

Hmm no worries - we do have a shared 'dev' setup however its meant to pull changes from git.. not sure if creating pages on it could have any repercussions. (sync wise) So I guess will try stick to the developers changing their mode when they need to do structural changes (at least for-now), and switch back to slave to ensure that when they commit the other machines are all on slave mode. Will see how it goes

Enjoy your Vacation!

---

Reply to this email directly or view it on GitHub:
#30 (comment)

[jonmifsud]

hmm might be a good solution then use the stuff from CDI to push to staging / production. Also what are the probabilities of 'breaking' development whilst creating new stuff like pages etc? as plan was to have management approve on dev and wouldn't be cool if someone makes a change and it breaks...

Finally when you make some config changes.. you would have to push config.php through git however you have to keep development as 'master' and your live as 'slave' so you would have to change the config prior to each required push?

[nickdunn]

Finally when you make some config changes.. you would have to push config.php through git

Nope, no config.php files in source control. You'd save the changes to a config.php.example file (in source control) as a guide, then make the change by hand to config.php in each environment.

[remie]

Nope, no config.php files in source control.

+1 for @nickdunn!

[jonmifsud]

just an update for anyone in need for this feature. Tried to implement it here feedback would be appreciated before sending a pull-request.