You are browsing a read-only backup copy of Wikitech. The live site can be found at


From Wikitech-static
< Fundraising
Revision as of 02:26, 30 July 2017 by imported>BryanDavis (BryanDavis moved page ContributionTracking to Fundraising/ContributionTracking without leaving a redirect)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

ContributionTracking is currently an extension that is deployed on the cluster, and on payments. It mostly allows us to save donation metadata to a table which currently resides not in the fundraising civicrm database, but in the drupal database for the drupal instance inside which civicrm is a module. The placement of this table in a random drupal database is clearly very silly, and as such it needs to be moved elsewhere.

Plan To Change The Contribution Tracking Table

Moving to its own database

  1. Create a new ContributionTracking database
  2. Import a dump of the old ContributionTracking table to the new database
  3. Alter the auto increment on the ContributionTracking's id, to be significantly higher than the current highest id
  4. Grant mysql privileges to user@host that need various levels of access to the new ContributionTracking database
  5. Change the references to the ContributionTracking db. This process will have to wait for a cluster deploy.
    1. Disable the queue consumer
    2. Update the references and credentials in the following places:
      1. On the Cluster
      2. Payments Cluster
      3. All Drupal/Civi Modules
    3. Re-enable the Queue Consumer
  6. Watch the old database to determine that nothing is still updating the old table
  7. Once you have determined that there is no movement on the old table, import all records that were created between the initial import, and the switch-over.
  8. Kill the old table

Schema Changes to the new ContributionTracking DB

  1. Analyze the ContributionTracking extension, determine what must be changed so the actual schema change can be done code-first or DB-first, and make the necessary changes
  2. Push just those changes out to the cluster
  3. Do the same analysis and make the same changes for extensions on the payments cluster which require ContributionTracking.
  4. Push those changes out to the payments cluster.
  5. Do the same analysis and make the same changes for all drupal/civi modules.
  6. Push those changes out to aluminium.
  7. Get the schema change ready to go
  8. Get the old crufty code cleanup ready to go
  9. Do the schema change and old crufty code cleanup in any order (shouldn't matter if you did the rest of this properly).

Al files referring to db1008