CiviCRM Community Forums (archive)

*

News:

Have a question about CiviCRM?
Get it answered quickly at the new
CiviCRM Stack Exchange Q+A site

This forum was archived on 25 November 2017. Learn more.
How to get involved.
What to do if you think you've found a bug.



  • CiviCRM Community Forums (archive) »
  • Old sections (read-only, deprecated) »
  • Discussion (deprecated) »
  • Alpha and Beta Release Testing »
  • 3.3 Release Testing »
  • Logging feature: how to differentiate entries in log tables?
Pages: [1]

Author Topic: Logging feature: how to differentiate entries in log tables?  (Read 1148 times)

greenmachine

  • I post occasionally
  • **
  • Posts: 58
  • Karma: 6
Logging feature: how to differentiate entries in log tables?
November 10, 2010, 12:32:40 am
Great to see the start of a logging feature. I can definitely see where that will build CiviCRM's stature in many use cases. But anyway: a quick question about how you intend the logging data to be used. I observe that each logging table appears to receive two new rows/entries each time a contact is changed. One row contains the old contact data values and one contains the new ones. But how is program code supposed to differentiate between those two rows, aside from the implicit sequence in which they appear in the MySQL table (when no ORDER clause is present)? The rows show identical log_date and log_action data.

As an example: the following sequential rows (omitting some columns) in log_civicrm_email:

Code: [Select]
| id | contact_id | email                                    | is_primary | log_date            | log_conn_id | log_user_id | log_action     |
|  3 |          2 | jblade3@test0509028.com                  |          0 | 2010-11-10 01:49:32 |         367 |           1 | Update         |
|  3 |          2 | jblade4@test0509028.com                  |          1 | 2010-11-10 01:49:32 |         367 |           1 | Update         |
|  3 |          2 | jblade4@test0509028.com                  |          0 | 2010-11-10 02:02:33 |         381 |           1 | Update         |
|  3 |          2 | jblade5@test0509028.com                  |          1 | 2010-11-10 02:02:33 |         381 |           1 | Update         |

Those four rows were created when I changed the contact's email to jblade4 in one update action, then changed it again to jblade5 in another update action.  I'm guessing there are two rows per update action so that I can grab any rows for a particular timestamp and compare the two for differences easily, but how is my program code going to know which of the two is the "new" value and which is the "old" value?


Another way, perhaps, to put this is: do you already have a function somewhere that can construct a  "version" of a contact from the log_civicrm_ tables (based presumably on a timestamp), and/or to diff between versions?

Donald Lobo

  • Administrator
  • I’m (like) Lobo ;)
  • *****
  • Posts: 15963
  • Karma: 470
    • CiviCRM site
  • CiviCRM version: 4.2+
  • CMS version: Drupal 7, Joomla 2.5+
  • MySQL version: 5.5.x
  • PHP version: 5.4.x
Re: Logging feature: how to differentiate entries in log tables?
November 10, 2010, 06:30:16 am

there were two db operations performed when u added jblade5 (according to the log). u removed the primary from jblade4 and inserted jblade5 (dont know if jblade4 was deleted from that log, maybe we should store it also)

that said, the current functionality just does the logging. There is no code/support to go back to a  specific version / revert changes etc. We'll be looking for code / financial support fromt he community to help take logging to the next step and might include it in the 3.4 make it happen

lobo
A new CiviCRM Q&A resource needs YOUR help to get started. Visit our StackExchange proposed site, sign up and vote on 5 questions

Pages: [1]
  • CiviCRM Community Forums (archive) »
  • Old sections (read-only, deprecated) »
  • Discussion (deprecated) »
  • Alpha and Beta Release Testing »
  • 3.3 Release Testing »
  • Logging feature: how to differentiate entries in log tables?

This forum was archived on 2017-11-26.