Search

I’ve updated this to 0.6.

http://github.com/nickdunn/db_sync/tree/master

Please note that this update is not compatible with previous versions. You will need to completely uninstall the original before updating. When you do uninstall, the log will be deleted, so if you have outstanding items in the log please export these first.

The code change to class.mysql.php in the core has also changed, so please update accordingly. This has made it much easier to update the extension in the future.

The biggest new feature of this release is the logging of queries by each page load. From this the extension infers what the action was from that page load (e.g. “section created”, “page deleted” and so on). The log export therefore looks something like this:

--
-- DB Sync from symphony-2.0.6 at Sun, 06 Sep 2009 10:28:43 GMT
-- 10 queries from 3 events
--

-- Event #1 (4 queries)
-- Nick Dunn at Fri, 04 Sep 2009 18:33:50
-- Section 'Articles' created

(queries here)

-- Event #2 (2 queries)
-- Nick Dunn at Fri, 04 Sep 2009 18:37:49
-- Section 'Articles' updated

(queries here)

-- Event #3 (4 queries)
-- Nick Dunn at Fri, 04 Sep 2009 18:38:11
-- Page "Article" created

(queries here)

This isn’t particularly useful in itself, but if you run the log against another build and receive errors then hopefully this should allow quicker visibility as to which queries are failing and why.

Just ran a 2000 query update from my local development build up to a staging server. So satisfying!

Nick, I noticed that it isn’t logging reordering of pages (or sections). Is this by design?

Is this by design?

Nope. This sounds like a bug, since every query run agains the sections/pages table should be logged. I’ll take a look.

Hmm, I’ve tested and this is definitely working on 2.0.8RC1. Did you recently update? If so, did you remember to add the line back in to class.mysql.php?

No, I am still on 2.0.6 with this website.

Yes, class.mysql.php is modified. It’s logging new pages, deleting pages, but not reordering.

Same for sections.

Nick, I removed any conditions from LogQuery::log to make it log everything — still no logging of reordering. Does this mean that the Ajax event does not invoke the MySQL::query method? How the hell can this be?

Ok, I’ve replicated this on 2.0.6 so I’m looking into it. Odd that it works in 2.0.8!

It also works on 2.0.7. But I have not found the problem on 2.0.6.

Since I will have to update this website anyway, I can do the update first, then deploy the updated version to the live server. Then I should be able start logging on the dev machine.

Got it. It is because the LogQuery class file never gets included in the AjaxPage. I was lazy and I only include the LogQuery class inside the top of the extension.driver.php. All backend pages will load the drivers of enabled extensions, seemingly except for AjaxPages (which makes sense, since an AjaxPage can’t be interfered with by an extension).

Since AjaxPage extends Page and not AdministrationPage, there are no delegates that I can hook into to load the driver (and therefore the LogQuery class).

I think. But quite why this works in 2.0.8RC1 I’m not so sure.

The quick fix here is to include the LogQuery class in class.mysql.php itself. A bit messy since it’s another change to the core… but it’ll solve the problem.

require_once(EXTENSIONS . '/db_sync/lib/class.logquery.php');

It works. Thank you very much, Nick!

No worries. The move in Symphony 2.1 to file-baed sections/pages will make this extension redundant… something which cannot arrive too soon! Database migration is always the most nervous part of my day.

The move in Symphony 2.1 to file-baed sections/pages will make this extension redundant…

I know. That’s why I didn’t want to cause too much trouble. I think that putting the additional line in class.mysql.php is a good solution. So my idea would be to add this fix to the repository and simply tag it 0.6.1 — “last release”…

It also works on 2.0.7…

Rowan alerted me to a fatal flaw in DB Sync for 2.0.7+ which means it doesn’t work properly (back in January). I have only just got around to implementing a fix.

Michael, if you’re using 2.0.7 then you’ll definitely want to update to DB Sync 0.7. However, 0.7 is not compatible with previous versions since I’ve had to change the way queries are logged. No longer are they persisted to the database, instead they are appended to /manifest/db_sync.sql.

This is because of changes to the MySQL class in Symphony which meant that the INSERT queries performed by the DB Sync extension would interfere with Symphony’s own queries, resulting in incorrect ID assignments.

If you currently have queries in your log I suggest you export these, uninstall 0.6, overwrite with 0.7 and re-install. The log tables will be removed from the database.

Sorry about this, but this is the only way to continue support for 2.0.7 and 2.0.8.

Database Synchroniser updated to version 0.7 on 26th of March 2010

Thanks a lot, Nick. (Actually I have not started yet, so I can simply install 0.7.)

Nick, have you tested v0.7 on Symphony 2.0.7? I don’t get it to log anything except some initial lines after enabling the extension:

-- 2010-03-27 21:30:11, Michael Eichelsdörfer, http://www.example.com/symphony/system/extensions/
DELETE FROM `sym_extensions` WHERE `name` = 'db_sync'
INSERT INTO `sym_extensions` 
                    VALUES (NULL, 'db_sync', 'enabled', 0.7)
DELETE FROM `sym_extensions_delegates` WHERE `extension_id` IN ('')

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details