Symphony.

Hi Guys, just installed the CDI extension on symphony 2.3 and also installed dumpDB (version 1.10) but CDI is telling me dumpDB 1.10 is not compatible, please install version 1.09. However 1.09 of dump DB is not compatible with symphony 2.3.

Any easy work around for this?

Looking forward to using this extension - it looks ace!!

Ah right... an easy workaround is to change the CdiUtil library in the CDI extensions lib folder. Just do a search for 1.09 and change it. Sorry, meant to update this but haven't come around to fix this.

@ChriZ: the link to the update wasn't available yet in version 1.0.1 so this might explain why you don't see it. There should be an navigation item in the System menu to perform the update or some text in the readme.

Ah okay! I guess I'll just use the url to update (couldn't find a link in the system menu)... this seems to be working quite well :)

on another topic, this will only update structural changes right? If I want to update the entries, I will have to sync a full db export across the sites, correct?

Thanks again for this great extension!

on another topic, this will only update structural changes right?

Yup, only structural changes. If you wish to update content, you should always first restore your local database from production and alert other users that they should not make any changes. After you are done with development, you can restore your development database to production. You can use the CDI extensions for this as well if you have the DBDump extension installed.

Remie, on my server the CDI extension is not listed, because of the ID you've given in the extension.meta.xml file. If I change the CDI to cdi everything works.

However, this brings up the question: what do you think is the proper name for the CDI? cdi or CDI? Either way, the ID should reflect the advice you give in the readme.

@Huib: it should be CDI, so I should adjust the readme / meta file.

Thanks.

Something else completely; feature requests. I am currently deploying my website with Capistrano, with softlinked manifest folders. This is working great, and rather reliable, too.

There are, however, a few things I am having trouble with:

Parsing the output from the update link

At this moment you have a very useful feature with the rollback. However, I'd love my deploy to be rolled back when the database doesn't import cleanly, to prevent the site from breaking. This is perfectly possible with Capistrano, but I do need to be able to tell when the import fails. Returning a server error (500) or any other error code would be very useful here.

The location of the dumps and sql files.

Currently, these are both hardcoded in the utility class/file, but I think it would be great if they could be set in the configuration. That way, it would be possible to put the dumps in my global directory which is persistent between deploys, giving me a nice backup. Because a rollback in Capistrano will delete the current dir, and symlink the old dir back, this means the db dump is also lost. So, if I accidentally rollback too far, I'll lose my DB dump...

I've been trying to work with this for a while; with a team of developers... unfortunately once in a while an issue comes up... I know there should be effort put into the 2.4 XML ID-less support, would love to but unfortunately I got my hands tied on the current setup.

I was thinking of going a slightly alternative way to the CDI the time being to try and allow multiple developers to work at the same time whilst resolving a couple of problems relating to 'inserts' and ids.

I was thinking of having an extension track the tables and id(s) which have been updated. Anything from inserts/updates/deletes + a timestamp. The extension would provide a way to generate 'SQL' into a trackable file. It would go through all the tables/ids listed. Takes only the uniques and copies the values from the tables at that point in time. Possibly also allowing the developer to choose the queries that they like to have pushed to production.

One can always think of putting these into separate files; but always running the query if it is actually newer then the 'last' update (for the entry). so if there was a query on the same field done afterwards but pushed before your change would be ignored. I'd appreciate if I got some feedback...

@gunglien, you might want to look into liquibase. For my needs it's way overkill, which is why I haven't used it yet, but it seems to be able to handle exactly what you're asking.

By the way, I'd like to stress this again: moving the structure into XML is not a solution for this problem. The problem here is that, while the end-result is important, the way it got there is also important. Let me put it like this; with code you don't mind if a function was renamed or removed and added again, as only the end result matters (you'll end up with the exact same code in the end).

However, with a database this does matter. If you remove and add a table, you lose all the data inside that table, whereas when you rename a table, you'll keep the data.

So the system will have to know the "path" to the current state, which you can not do by simply diff'ing two endstates.

I would like to make a suggestion about the naming of this extension re the issues Huib encountered, as have I.

Convention is lowercase names for folders and lowercase names for extension classes, which this extension mixes up. Please can you follow convention?

PS

Viktor (my manager) is implementing liquidbase here at Airlock for a build system. If anything comes of it (it may be months yet) I will request community exposure on this idea.

problems relating to 'inserts' and ids.

Also, I logged an issue about this here, so please any backup will benefit me.

@designermonkey, thanks for bringing that post up again. Despite what Nick sais, merging the transactions is the only way to sync two databases.

There is one thing you might want to look at; because the id's are auto-increment fields, you won't need them in your sql, so you can safely leave them out in your exporting logic.

I'm not exporting from Symphony, this procedure I am thinking about is completely separate from Symphony. But thanks anyway.

Question: Is there any particular reason that the CDI tracks queries, rather then for example using delegages such as SectionPostCreate, FieldPostCreate, PagePostCreate & their edit variants?

By running the delegates you could still re-build the queries on the server side I believe.

Its to do with the ID numbers in SQL

but wouldn't you be able to take the insert/update id from the PostCreate/Edit? Or otherwise get it from the db (though not so cool) I think it could be more flexible haven't exactly tried it yet but was thinking about it.

@gunglien, from what I understood using delegates is possible (I coined the possibility a few pages ago), but the problem lies with extensions: not every extension will have delegates at the right places, and it will be a hell of a job if the extension needs to know of every delegate in every extension to be able to sync modifications in extensions...

So, for now it is easier to simply track the database changes directly. However, I do agree that tracking delegates is a way better approach because you are able to tell the user exactly what will happen (rename section, add page, etc).

Not all the IDs are tracked by the Manager classes, but to make sure the systems both work in the same way, all IDs must match.

I'm current that not all IDs are tracked but it could be a starting point even if fetched manually from within the extension (not standard practice but would look like a better flow)

When it comes to extensions.. that's something else I guess. though I'm not so sure how many of them actually do structural/tracked changes (bar for the installtion / update procedures) which I'm sure that they could probably be tracked via the install/update delegates.