Symphony.

I have encountered problems multiple times. One problem happens when you try to add fields to existing sections. I've tried checkbox, reflection, order entries, etc. CDI's SQL creates new rows in sumfields, but not in sumfieldtypename. I would try to remove the field and re-add it, and it would just create 3 of these rows. Somehow, one of them ends up working correctly. I need to remove the others manually in the database. This has happened at least 4 times.

I have had no problems with pages, so there might be a conflict with one of the field type extensions that I have installed.

@re order entries. There was a typo in one of the regex matches... which meant order entries table changes were never tracked... as for the others never had issues myself.

gunglien, is there an update for that order entries issue? I think i've encountered the same issue as well where I would get three of the same field and if i deleted the wrong one, the entire section would just stop working.

on other matters, I feel like I'm doing something wrong when using this extension. Whenever I move updates from my dev environment to my staging environment, it's never updates the table with any sort of values. It will create the table, but there are 0 rows created which then makes my staging environment not in sync with my dev env.

Dev is the master instance while my stage is a slave. When I go to the update url, it executes the queries, but still, no entry data is filled out. Is there something I'm missing with this? This is a consistent issue that I've noticed with my set up.

@wldtan, Currently the way the extension works it does not update you Entries. If you want to update entries, you run risks of having inconsistent data between local/staging/production servers.

If you want to try, all you have to do is modify one line in the extensions which stops all entry data from being logged. Keep in mind that a new entry on production will not be reverse replicated in this setup.

As for the fix you can look here. The suggested change above should be around the same lines.

When using Continuous Database Integration, on the "slave" instance, I have my Synchronize CDI Slave url. So how does one use the URL to update this CDI Slave instance with curl?

I can't find any instructions or documentation showing how one would do that. I know I can use the terminal, but what curl command options do I use?

Could someone post an example?

I have figured out how to get curl to work, but to be honest, I haven't been successful getting it work period.

I upload the manifest/cdi/cdi.sql to my server in the manifest/cdi folder on the server and then I click on the Synchronize CDI Slave link and I keep getting this error...

ERROR: MySQL Error (1146): Table 'pcpc.sym_cdi_log' doesn't exist in query: DELETE FROM sym_cdi_log` WHERE `query_hash` LIKE 'ea4888cd8931463078fe81b718c4c2bf'`

Any thoughts on what I might be doing wrong?

The CDI log table only exists on one of the instances, and I don't remember which one. One of your instances (either master or slave) should have the table.

OK. I'll take a look.

It's the slave instance. Slave keeps track of what queries are run so that it can skip/prevent repeats.

I'm hopeless! I can't get this to work! Here is what my Master looks like…

Here's what the slave instance looks like…

NOTE: click on the images to enlarge the image

On the MASTER instance, under the last 5 queries logged… I always get the following…

DROP TABLE IF EXISTS `sym_cdi_log`;

Then when I upload the manifest/cdi/cdi.sql file to my server and the click on the Synchronize CDI Slave url… I get the error that I listed above.

NOTE: I've checked to see if I have the sym_cdi_log table before uploading, and I do, and I after I click on the Slave CDI instance URL it gives me that error and then I look at the database and see that it does remove that table sym_cdi_logbut it gives me an error.

I would suggest you re-install everything. You shouldn't be deleting from sym_cdi_log in the first place.

@Pat, I have reinstalled it several times and the same thing happens. Thank you for the input. I'm not deleting the log the extension is doing that. Thanks for your help.

Is there some documentation or a "step by step" on how to setup and use CDI extension?

Does your cdi.sql file ever get filled with anything? Or just the drop table

It does get filled with changes; but it always has the following to start off the cdi.sql file...

{"0":[1379012166,1,"af7e47e8381656e33658895b207cb78d","DROP TABLE IF EXISTS `sym_cdi_log`;"]

@bzerangue, you're not supposed to clear your CDI file, unless you are 100% sure you've sync'd your databases.

One reason that query could potentially be getting logged is; if your local CDI would be a 'slave' instance and then you change it to master. The default CDI removes the table from the master instance. I'd suggest after installing and setting up CDI to clear the cdi entries before you continue. Should resolve the problem. (Installing CDI on production obviously cannot be done by CDI)

One reason that query could potentially be getting logged is; if your local CDI would be a 'slave' instance and then you change it to master. The default CDI removes the table from the master instance. I'd suggest after installing and setting up CDI to clear the cdi entries before you continue. Should resolve the problem. (Installing CDI on production obviously cannot be done by CDI)

The problem is that I have uninstalled and reinstalled CDI and it ALWAYS defaults to "Slave". I then clear the logs and change it to Master. Then I save the changes, return back to the Preferences page that DROP TABLE query is ALWAYS there.

Here's a quick video showing you the problem.

NOTE: I am running the master from my local, development environment.

Did you try uninstalling by deleting all the files?

@Pat - Thanks. I went ahead an uninstalled the extension. Deleted all the files, the extension files and the manifest/cdi files. I reinstalled and it seems as if the DROP TABLE is NOT coming back. That might have fixed it. I'll do some more testing and report back.

Thank you.

I am using CDI on a new project, and once again it’s not working properly. It’s inserting rows into sym_fields, but not creating the corresponding sym_entries_data_## table or adding the correct row to sym_fields_FIELDTYPE.

@pat - if i'm understanding this extension correctly, the reason for the sym_entries_data_## not being entered is b/c this extension only tracks structural changes, not actual entry data. I had the same issues when I was first trying to get used to this extension, but once I realized how it worked (for the most part), i then was able to know what to expect from this extension. The biggest reason for not creating the entry data simply is b/c your dev, stage, prod envs will more likely than not have different entry data to begin with. If this extension were to keep track of actual entries, then your different environments could get hosed real fast. That aspect of this extension is a pain in the ass, but I believe the right thing to do. It sucks when you've entered a bunch of data on your dev environment and then try to move all this stuff up to the subsequent ones.

I've been fortunate enough that I am working on a site where the admins do not update things at night so I typically pull down the prod database to my dev env, do the work (right now it's not as much as before), create the entries, then promote it back up to prod. Then with all of that up on prod, I can continue to modify on my dev while the CDI logs structural changes and then use the cdi.sql file when I want to push some more stuff up.

That being said, I'm seeing one issue at the moment - when I create a new section, this extension does not log that section and does not create the corresponding row in sym_sections which I thought it was supposed to do. Am I mistaken on this?