Symphony.

A quick question about symphony 2.2.5 I know it is not officially supported, but it seems to work quite smoothly!

It seems to have a problem to update member role permissions, like create, don't modify, modify own, modify all, (from the members extension). Is this a known issue or do I have a syncing problem?

Thank you!

I'm testing this extension on a server which I reach through lhost file. When I try to install the extension I got an error: Could not find extension CDI at location ...

Is this due to the lhost file?

No, you're probably using a server that has a case sensitive filesystem.

If you change the extension folder name to CDI in uppercase, it should fix it. It's happened to me loads, and I always forget it.

@designermonkey It just goes the other way. No error with lowercase but not shown in the extension list, though with an sql dump and the extensions enabled it shows in the preferences.

But the synchronize gives an error: WARNING: You are not calling this page from Symphony, the CDI extension is disabled or you are running the queryies on the Master instance. No queries have been executed.

Um, I'm at a loss then...

Ah, I've ran into this issue before, I believe it's because the CDI checks for a certain object to be present, but in the 2.3 update this object is no longer there. If that's not it, check your config, as the slave setting is probably missing (it was one of these two, I can't really remember... A few echo's should point out where the issue is).

@creative dutchmen What do you mean with a few echo's?

The complete message is:

Could not find extension CDI at location /var/www/vhosts/domain.com/httpdocs/extensions/cdi/extension.driver.php.

Sorry, I was referring to the other issue you were getting when you just tried to sync the database.

About security:
... I strongly advise that you alter you .htaccess file to prevent your webserver from exposing these files.

What you guys suggest to I have this prevetion?
When I try access mywebsite.com/manifest/cdi/ have forbidden error already.

Thanks.

@plenaforma Try renaming folder to lowercase CDI -> cdi and change the xml meta id to lowercase too.

I reported on Github: https://github.com/remie/CDI/issues/39

I've been playing a bit with CDI & the PostQueryExecution delegate; as I've had some problems working on group projects with other developers. and I was wondering weather it would make sense for the PostQueryExecution to also have in its context the last Insert Entry ID. [or otherwise obtianed]

Use-case I'd like to modify the CDI to add the Insert ID to some insert statements. Basically creation of Fields uses entry IDs all over the place; so I want to keep these fixed. This way if someone pushes a wrong 'id' or something that already exists it throws an error rather then carries out all the respective inserts but having the fields & table-name not matching up.

Additionally in case someone knowledgible is looking in, any idea why the json is sorted every time on getCdiLogEntries()? just a cosmetic thing so one can reference to a query? As it doesn't seem this is tracked & the time-stamp used for the ID should be good enough I guess.

Is it important to do this work as we prepare to move to an XML based schema? Personally I would wait and see how that will affect this extension after 2.4 is released.

It could be a while though, I'm not too sure of Brendan's timescale expectations on 2.4 yet.

Ye I know the XML stuff coming up in 2.4 so it would be redundant I guess then; I think I wouldn't actually need to 'touch' the core as such but I need to set something up for an internal workflow - team of 3. Since they're always switching developers to work on different projects... and takes a long time to approve I need to come up with an internal structure to have this work properly up till everything is updated with 2.4 (so that might actually be some time after 2.4 is actually released)

@gunglien, this might be something interesting: mysql supports auto_increment_offset and auto_increment_increment. What these do is making sure there are no primary value collisions (entries with the same ID's), so merging two databases is very simple: just import them both and you are done.

So, why is this so awesome for the CDI? Well, because if you were to use these settings correctly, actually merging the databases from multiple developers isn't as much of a problem anymore. The only problem you'll have is when developer A deletes a section, and developer B does something with that section afterwards (because he hasn't deleted it locally). However, that can be easily avoided by a simple rule: before deleting, ask.

@creativedutchmen indeed it was exactly what I was after. I'm going to use the auto_increment_offset what I wanted the CDI for is to be able to merge multiple branches in different order obviously on production without having anyone do any queries or choose any sql. When stuff is pushed through git we can automatically hit the update urls and we'll be done.

By using different offsets and keeping the Insert IDs in the queries it can ensure that there will be no conflicts when pushing up or merging another developers work.

@gunglien, exactly. Do not forget to set the auto_increment_increment to the number of clients you want to sync, though, otherwise you'll still end up with collisions.

What I like most about this approach is that you can actually sync the data from the liver server continuously to the development server without the fear of overwriting your sample data, or worse: section and page settings. That's very useful, as oftentimes you'll have to test a new feature on "real data" rather than sample data to see how if it really works the way you want.

Love to see what you come up with!

Just throwing an idea out there, although I'm sure Remie, and other have thought about this...

Would it be too hard/complicated/troublesome to build a system that basically runs a diff on both databases at once, and returns a set of sequel commands to run on both databases to re-align them?

I mean to turn both databases off (maintenance mode) and run the program, which basically builds the structures for both databases, aligns the IDs and then writes over each database.

I must say I have no experience with auto_increment_offset so i'm really interested in what @gunglien is going to come up with...

@designermonkey, yes, this is a very hard thing to do, because with databases the order and the actions matter - deleting and recreating a table is not the same as renaming a table. This makes diff'ing on state nearly impossible.

Let me give an example: imagine we are syncing our databases, we started with identical db's, with a set of tables and entries. Now, when I delete a table, and we sync the data I expect the table to be deleted on your end, too. However, the diff has no way of knowing if it's me that deleted or you that created.

And, just another example to show how difficult this is: imagine you rename a table from A to B, then how does the diff know what happened? It could have been that you deleted A, and created B or you've renamed A to B or maybe I I created A, while you created B. Difficult.

Now, let's make it even more difficult, in the example above, say you've modified a table so that a field is deleted, and I've created a few entries with data in that field. This is clearly a merge conflict, which can never be solved without knowing the context - much like the conflicts in Git. So, no matter how advanced your solution might be, and how smart it is, there are always situations where the software simply doesn't know.

However, what @gunglien and I discussed above will make merging two databases a whole lot easier, but we will always need the transaction log for that. The benefit of the configuration details I posted is that ID conflicts will not happen when creating new content. So unless you are doing stuff that will generate a merge conflict anyway (modifying structure on one and, while modifying data on the other), the merge should be able to go automatically. But, let me state again, a transaction log of some kind will always be needed.