Symphony.

Hey Nick, it looks like the GitHub repository still has the old lib/class.logquery.php file in it that refers to Symphony::Engine(). Took me a while to figure out why my upgraded installation wouldn't let me log in... :D

For those interested in continuous integration / working with DTAP environments, I can use you help testing the Continuous Database Integration (CDI) extension!

Euh.. right... duplicate post... something is going wrong here.

@nick

Well, this is the first time I had to practically use this extension and it worked perfect. I admit I was a bit nervous :))

I have a strange issue with this. I encountered it before but didn't mind it. I thought it was because I messed up Dev DB.

I have a Prod going. Copied DB to Dev. Made changes. Now, on pushing structural changes to Stage (same as Prod), I'm missing one entry (a Date / Time) from table sym_fields.

Changes include: creation of a Section (Comentarii; id=22) and edit that section with adding another field (Date / Time). It seems the queries needed to add this field are not working correctly.

In past this happend as well with adding new fields to existing sections. Some of them were missing from sym_fields.

I attached db_sync.sql.

Is just me or someone else stumbled on this?

Edit:

Got it. Queries for Order Entries field are not logged. Look in attached file at line 46.

Filled an issue on Github for this.

Attachments:

db_sync.sql

Hmm are you able to replicate this consistently? I just tried locally and an Entry Order field is definitely being logged when added to a section.

This evening after I get home I will try and replicate it.

@nick

Tried to replicate it, but in vain. I'll keep an eye on it and when it appears again I'll let you know.

Thank you anyway.

Wow, can't believe I hadn't integrated this into my workflow before now. Awesome.

Hi

I have a few questions about using the dbsync extension. I have read through the thread but I would just like to clarify a few things before I dive in. I am slowly getting my head round git but I am not completely there yet.

My situation is this. I work in a team of 3 people. I am the lead developer but on occasion other members of the team also do some development work, particularly for maintenance or adding simple features. However we don't share an office space or even a time zone for that matter. We have a dream host account that we all have ssh access to. Our current workflow has been to clone symphony on our dream host account, and work directly on the server files using coda i.e. no version control. We have been burnt a couple of times overwriting each other but generally it has worked. However the sites are now becoming more complex and we are also having to add features to live sites which is causing some major headaches.

The plan is to implement the development, staging, production model.

1. Create 3 databases, development, staging and production on dream host account

2. Create 2 domains: mysite.com and stage.mysite.com

3. Clone the symphony repo on my local machine, create a new branch mysite

4. Checkout mysite and add extensions as submodules?

5. Install symphony on local machine using MAMP, telling it to use the development database on dream host account

6. Code up first version of site and push to repo on dream host account

7. Clone repo on dream host account for stage.mysite.com

8. Copy development database into stage database and check everything is working on stage.mysite.com

9. Install dbsync on my local machine, edit config file, then push to repo on dream host

10. Tell other members of team to clone repo from dream host to their local machines

This is where I get stuck in my thought process. Now that there are multiple copies of the site all using the same database how does the dbcync.sql file work? Does this file reside in everyones local copy of the repo and keep track of all changes from all developers? If one developer adds a page, for example, will the other developers see this in the backend but only see the xsl file once the developer pushes to the main repo and everyone else pulls from it?

As you can see I am getting confused.

Any help on this would be greatly appreciated.

Nick's earlier comment does a great job explaining how to keep a dev, staging, and prod environment in sync with this. But I'm struggling to understand how different dev branches can be maintained.

If I keep db_sync.sql under version control, its contents will change when I switch branches. Yet the actual database won't change. Would db_sync.sql no longer update the database correctly?

Alternatively, if I don't keep db_sync.sql under version control, it will contain any changes from any branch. It will stay in sync with the actual database, but won't be available in a commit.

Am I missing something obvious, or is there something else I need to do for different development branches?

I'm guessing this is more of a git question than Database Synchroniser-specific, since the same will be true for any file you want to remain consistent between branches. Would you not be able to commit and then merge when changing branches? Your best bet might be to exclude it from version control entirely.

For any given file, git handles this fine, though. The issue has more to do with versioning databases. The problem is that switching branches in git doesn't change the database state. So db_sync.sql won't map to the current DB state correctly. And excluding it will face the same issues (DB updates from multiple branches in db_sync.sql don't all align with the current state of the DB, at any given point).

While I'm still not 100% sure of what you're asking (are you referring to multiple local dev branches, one for each new feature, that you can jump between?), if I'm assuming correctly, then I don't think this can ever be solved since Database Synchroniser relies on you following linear steps. Each step is cumulative. Do you share the same database instance between all of your branches, or a separate one per branch?

I think I know what Anhedonia is talking about, but this is not something that is currently implemented for Symphony.

The database schemes of our web applications at work are all versioned. There is a log table in each database that keeps track of which schema changes (SQL script) has been executed (hence which version the database is). There is a base schema (version 0) from which all changes originate.

I can clear that log table and run a script and it will update the database schema from 0 to the latest version. When I switch between projects I can use this to update the database to the version the project is working on (which is usually ahead of our production schema). The SQL scripts with schema changes are designed to be repeatable and thus backwards compatible (which basically means: no deletes of tables, views, columns, stored procedures, etc).

Although this works great in the development environment, we have never actually dared to run this on production. In addition, implementing this uses a lot of storage. It is not as lean and mean as Symphony users are custom to. There is a lot of data redundancy and history for performance and business analysis reasons.

But hey, we are talking about a process that is used to manage 15+ databases for 25+ services, web applications and scheduled tasks. It contains over a terabyte of data and is accessed by more than 3.5 million users per month that generate over 2.5 billion pageviews per year (excl. traffic on mobile devices).

I think the use case is non-existent in these small projects where you use a CMS like Symphony, Drupal, etc.

you share the same database instance between all of your branches

That's exactly what I mean. Do you maintain different copies of the entire database for each development branch (and would each copy be largely the same, then)? Is switching the database something that can be handled in git configs? I am not familiar with that.

What remie mentions is something different, though ultimately I would like to version the database changes. I haven't found a good solution for this yet, though (I spent a lot of time getting SymmetricDS working on my local computers, only to then realize that it doesn't seem to handle table creation, so I abandoned it).

Do you maintain different copies of the entire database for each development branch (and would each copy be largely the same, then)?

I do not, but I thought that is what you are asking about. I use one database, but have to be mindful when switching between branches when developing features, since I know that all changes from all branches will be logged (regardless of whether I merge the features into my master branch or not). I don't version control the SQL migration file.

Ok, that's what I was wondering about. So you just keep mental note of any changes in a working branch that would hit the database, and account for that as it comes up, I guess? I suppose if a branch involved extensive modifications, one could always do a complete mysql dump. Thanks for clarifying this for me, though.

I enabled this (using the code before Nick's 2.3 update) for a 2.2.5 site today. Added a section and don't see db_sync.sql in my manifest folder. Am I missing something?

Are the permissions set correctly?