Search

Is there no way to sneak a delegate in there so it can be modified via the extension?

How sad. No new fancy delegates that could handle the logging process?

Removed as no longer relevant

Is there no way to sneak a delegate in there so it can be modified via the extension?

Possibly. I didn’t in the past since each delegate call required a database query to look up subscriptions. So if a delegate was executed on each database query, then this would effectively double the queries during a page load!

In Symphony 2.1 this changed so that delegate subscriptions are cached in an array (in memory) once when a page loads, so adding a delegate into the MySQL class is now a possibility.

This won’t make it for 2.2 but perhaps Symphony 2.2.1.

Nick, as joe_g mentioned a while ago this extension does not log updates/additions/deletions of fields in a section, at least not under Symphony 2.1.1 with version 0.8 of this extension.

I’ve debugged a bit and it seems to be due to the “self::$id != self::$previous_id” check. As far as I can tell, this prevents the extension from logging more than 1 query on each request. I’m not sure I understand why this is necessary? In which cases is this check needed?

this prevents the extension from logging more than 1 query on each request

It shouldn’t do. The ID refers to an “event”, which I consider as being one page request. So when the class is initialised a unique event ID is created and is used for all SQL statements that occur throughout the page load. I store the SQL statements along with the ID, so they can be grouped into individual actions.

I did briefly look into the page-saving bug and figured it was a Symphony bug and not my extension. I think it was down to a change in the MySQL class which means that a DELETE or INSERT does not run through the query() function, and so never gets logged by the extension. But this was before Christmas and my mind is hazy!

When Symphony 2.2 is released, which improves stability by having more robust static manager functions, I’ll delve deeper into this.

I’m not quite following you Nick. I’m using the 0.8 release (not bleeding edge master branch, if there’s any difference).

On line 9 in class.logquery.php we have:

self::$id = md5(uniqid('', true))

Which as far as I can see only generates a unique value based on the current time in microseconds. Then on line 31 we have the following guard around the whole logging:

if (self::$id != self::$previous_id) {

Where self::$previous_id is self::$id after logging one query. And these are static variables meaning they are persisted through the whole request.

I disabled the guard locally and that resulted in a lot of queries being logged for each request, both UPDATE, DELETE and INSERT queries.

Maybe this is a bug. I think this check is there so that the “meta” line describing the block of queries is only written once for each page load (each instance of the static class) rather than each time a query is logged. So the condition you mention above should only be around the string concatenation of the date, author and URL, but not the query itself. I haven’t looked at this extension in such a long time I can’t really remember much about it I’m afraid, but that sounds logical.

Confirmed: https://github.com/nickdunn/db_sync/blob/53fd6cd9a63022dbe6c27680b4cb90f2aacfd43d/lib/class.logquery.php

See that the condition never used to be around everything. Must have snuck in in a later version.

Ah, that explains the reason for the whole self::$id and self::$previous_id logic. The repeating meta information was actually the next little thing that bugged me when I simply disabled the whole conditional :)

I’ve also done some improvements to the query filtering, so I’ll create a pull request on github with a couple fixes later.

The issue here is that both staging and production environments share the same database. So I guess it makes more sense to have two separate databases, one on staging and one on production and sync when changes are made

Yes, separate them out. If you’re sharing a database between the two then staging isn’t really staging.

Here’s a quick example of how we usually work with db_dync:

Each developer runs the site locally from their own Apache instance (often MAMP), getting the files from source control (SVN or git). There is a development server (dev) which has an Apache virtual host set up running the site (also updating from source control, manually via SSH). Developers modify their Symphony config.php to connect to the database on the dev server — they do not install the Symphony database locally.

When a developer wants to make changes to Symphony that impact the database (modifying sections, pages, installing extensions etc.) these are first done on the development server (dev.[project].airlock.net/symphony) so the changes are made to the database. All developers then see these database changes immediately.

The db_sync extension is installed and enabled on the development server. Each time a change is made, the db_sync.sql file on the development server is updated with additional queries.

When it is time to release to the staging server, the following happens:

  • a development freeze is called, nobody touches the database until further notice
  • a developer commits the db_sync.sql file to source control from the development server
  • the staging server is updated from source control and the db_sync.sql file is run against the staging database

Pushing to production/live is usually a similar process, although generally not from source control. Instead we rync files directly from staging, so that we can exclude certain files, and we include the db_sync SQL file in the deployment scripts.

Naturally, always back things up first.

db_sync workflow

If you’re just working solo then you probably don’t need all of this. But working as a team, we can add developers to the above diagram without issue — everyone shares the one database, and all Symphony changes are made to the development server. The minute someone starts working solo (creating a section by accessing /symphony on their own local server and not through the development server) then this will be missed by db_sync and the whole process fails.

I’ve also done some improvements to the query filtering, so I’ll create a pull request on github with a couple fixes later.

Thanks! Incidentally, me too. I’ll wait to see what your changes are before adding mine so hopefully we’re not replicating work too much :-)

@nick

Until the release for Symphony 2.2 which you intend to do, is there a way to bypass this bug

this extension does not log updates/additions/deletions of fields in a section

in Symphony 2.1.2. with 0.8 release?

Any chance this becomes available on 2.1.2?

Nick, we should definitely merge our extensions. Schema Migration and Database Synchroniser. What do you think?

I need to investigate these bugs a bit more, so yes I do plan on updating for 2.2, but it’s not at the top of my list.

Nick, we should definitely merge our extensions. Schema Migration and Database Synchroniser

There’s common ground that we can definitely work from :-) I think we use fundamentally different approaches so perhaps there’s value in keeping them separate, but I will have a look over Schema Migration when I get a chance (perhaps once 2.2 is released?) and we can work out where the commonalities lie.

I once planned a full UI for managing the .sql files this extension generates, so that you could push it from one build to the next, backup and apply it, and roll back if necessary. But it became so complex that I thought it better to keep it as simple as possible and allow developers to perform this step themselves, especially when using something like Capistrano.

Here we go Nick, I’ve sent you a pull request with a couple small but important fixes I made to the current master branch.

There’s a lot of obsolete code (the logviewer stuff and filtering of dbsync queries) which could probably be removed, but I haven’t familiarised myself enough with the extension yet to properly evaluate if it should simply be removed or brushed up and re-introduced as features.

Cheers Froded. I had already made some changes so this didn’t merge, but I have added your changes manually.

https://github.com/nickdunn/db_sync

Correct, the LogViewer class is no longer required. Originally this extension logged queries into the database directly, so this was a way to view activity. This has been superseded by Craig’s Tracker extension which is designed purely to log backend activity. (Tracker needs an update too, since useful new delegates have been added in Symphony 2.2.)

Eventually I’d like to allow this extension to once again log to the database rather than a flat file. This would allow a better multi-deleveloper setup, allowing developers to access /symphony/ on their own local builds, while connecting to a central database, and have all of their changes logged centrally. But it makes sense to remove all of this for now, as the approach I took in the past probably wasn’t the best.

Will tidy up and re-release.

@nick

By the way, you should update the readme.

“Requirements: Symphony 2.0.7, requires a small modification to class.mysql.php (see below)” etc

I think this is still the case — the extension should work on 2.0.7+, and still requires a change of class.mysql.php.

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