Symphony.

Thanks for the interest! I am halfway in getting everything to work the way I want.

It is quite a lot of work to setup, but I am pretty sure it will be worth it in the end!

I'm really looking forward to your article. Please let me know if I can help proofread or edit.

Remie, from the other thread:

is there a possibility of importing the sql from the command line

Yes this is possible. I have a CI server running to do the deployment of my projects which includes a script to call the CDI update mechanism. I use Curl to make an http call to www.example.org/symphony/extension/cdi/update/. So on my production server, whenever I do a deploy it automatically runs the DB update to sync my changes.

I have one (rather important) question about this: how are you authenticating yourself to the service using Curl? I do not really like the idea of a magic link that will import sql files that everybody can access.

Also, I looked at making the script call able from the command line, and it would require quite a bit of trickery to get it working.

Can you please give a few pointers on how you have managed to do this?

@brian: if you would like to proof read, yes please! I would really appreciate it.

I will send you a copy of the article when it is done, thanks!

Huib, I'm happy to give it a once over too...

Oh crap... I didn't check the site for one day and now there are 13 new posts in this thread! I'm going to read up on them now, but @huib: if you want you can contact me offline. I will sent you my contact details through github and we will see how we can sort this out into making something that everyone can benefit from!

I have one (rather important) question about this: how are you authenticating yourself to the service using Curl? I do not really like the idea of a magic link that will import sql files that everybody can access.

@Huib: right now it is indeed not secured, but there is little or no security thread. The extension will not execute SQL scripts that have been executed already, so if you run the update directly after a deploy, there will be nothing for the PHP script to process.

Can you tell my what are your considerations that you would want to make this private? What are the risks to your opinion?

@remie: pull request sent.

Ok, so today I went through a lot of hoops (again) to get this thing to work reliably. So far I have managed to setup a local installation, push to my development or production server, have it backup the database, and recreate all structural changes I made locally.

Pretty freakin' awesome.

However, I am struggling with a few issues: one is the location of the SQL files generated by the CDI extension. They are currently in the manifest directory, which means I have to track them with the Symphony repo, which might make future updates a bit harder (they will very likely merge cleanly, but still, I prefer to keep my Sym repo as clean as possible). If there is an easy way to move those files to the workspace, it would be awesome.

Another issue is (are?) permissions. Because I forgot to enable ACL when installing my server, git will not set the right group permissions (write), so this required me to change permissions every now and then, which is not something I'd like to do on a live server.

Anyway, just wanted to give you a quick status update, I hope you will enjoy the end result as much as I enjoy figuring it out!

Continuous Database Integration (CDI) updated to version 1.1.0 on 31st of May 2012

The 1.1.0 CDI extension is 2.3 compatible and uses the new PostQueryExecute delegate. This means it is no longer required to make modifications to the core files.

I'm working on a more detailed tutorial on how to use CDI in an DTAP environment setup. So there is more to come, but 2.3 compatibility is a good start :)

Nice!

The starting date for my big project, which will need the deployment with GIT, is starting to come very close, so I will finish writing about my findings soon!

@Huib: I'm planning to release 1.2.0 next week which will include a feature request to allow multiple developers to share structural changes between instances. Perhaps this will be of use for you?

I'm planning to release 1.2.0 next week which will include a feature request to allow multiple developers to share structural changes between instances. Perhaps this will be of use for you?

Great news! If you manage to pull that off you've earned my eternal respect.

It will affect me in the way that I will have to see if my workflow will allow this, too. Especially if I'm going to write an article about it;) I will be the only developer on the upcoming project, so my workflow there won't change.

Hi Guys - is there a nice config somewhere where I can define tables that should not be tracked?

For example search-index which is a content-based table is updated every time I save a related section . And this logs into the CDI - since this is content I would not like this to be tracked obviously. Similarly other extensions might have some custom content-related sections or cache tables that I've worked on personally. These I would not want to track. Would be cool if there is a config to set a list of tables at least.... or a way it could be obtained from the actual extensions which to track / not to.

I guess for now would have to edit this myself.

@gunglien: this is currently not an option. Could you create a feature request on github for this? I think this will be an advanced feature which will be implemented without UI (config file only). But I guess it could be usefull!

remie, how is the multi-user thing coming along? Will the CDI ever support it, or is it more difficult than you thought?

@huib: I've been on vacation the last couple of weeks, so no progress yet :) I currently have two PoC's: one where it works with a username/timestamp combination to order the SQL statements that need to be executed. The second one tries to make it the change transactional by identifying the SQL statements that have been executed during script runtime and combine them to a single transaction. If I manage to sort out meta information about the change from the queries, this could provide useful in debugging.

Anyway, It is indeed rather difficult and I think it will require some heavy testing before this can be released. However, I will make my progress available in a separate branch so you can play with it if you like!

@remie sure just filed a report here.

Been testing the CDI from a local / dev environment over last week seems to be working like a charm :)

Have not really tried having multiple users working on the same project yet (shouldn't happen all too often with our setup) But in such case I'm very confident it would work using a shared database.

It's not ready for release just yet as it still needs a bit of refactoring but I've been working on a project to allow multiple users to collaborate. (I didn't realise you were doing this)

Just posting it as a FYI, not trying to tout it over CDI (I did borrow some bits of the code!)

https://github.com/davjand/database-migrations

@remie It's not bullet proof in functionality but stores each transaction in a separate file which can thus be managed by GIT. Whenever it makes a query it tracks it in a csv file (which must be added to gitignore). Whenever the list of files is synced via git then the interface can figure out which are new.

This isn't clever though, it's a simple diff - if one query was to delete a section from user A and a later query was to insert an entry into the section from user B (at a later timestamp) then errors would occur.

It's intended to be part of my symphony continuous integration setup (https://github.com/davjand/ci-workspace) which again is still not quite ready but will be soon. It does work if anyone wants to play with it though