This page contains the specs for upgrading the database, generating sample data, and generating scripts for migrating data from the old schema to the new.
The CiviAccounts schema changes involve new types of changes to the schema that need representation in the xml and processing in GenCode.
New Attributes:
- <change> contains the version number when there was a change in a field's or table's name. As of r34140 I have made some changes to title, headerPattern, comments and other attributes without setting this attribute, meaning (I think) that no SQL will be generated to modify the field.
- <changedName> contains the previous name of a field or table prior to the <change> version. If specified for a table, then records in the <changedName> table will be migrated to the <name> table during upgrade / migration. Providing the same value in the changedName field for several tables allows one table in v4.0, eg civicrm_contribution, to be copied into several tables in v4.1, eg invoice, invoice_line_item, and invoice_line_sub_item. Values for fields allow SQL statements to map contents from an old field name to a differently named field, eg contribution_type_id to account_id.
- <changedFilter> contains a MySQL WHERE clause phrase that filters which records should be copied from old to new table when there is a <change> attribute on a table. For example, while each record in the 4.0 civicrm_contribution table needs to create a corresponding record in 4.1 in civicrm_invoice and civicrm_invoice_line_item tables, the 4.1 civicrm_contribution should not contain membership and participant line items. As a result, its changedFilter is "id NOT IN (SELECT contribution_id FROM civicrm_participant_payment UNION SELECT contribution_id FROM civicrm_membership_payment)".
- The 4.1 schema contains snapshot fields that are write-once, read many times. I suspect (but haven't checked the code to be sure) that the DAO provides a list of fields with types that are used to automatically generate html at the BAO or higher levels. If so, there may be a way to reduce special coding for this new class of fields by indicating in the xml schema that they are writeOnce. If not, then this attribute should be removed.
To improve the quality of our testing in the absence of significant uptake in the alpha and beta release program, we should solicit from CiviAccounts 'partners and friends' organizations sample databases to test upgrades on. We should ensure that there is a good coverage in these databases of all financial information, eg. events, memberships, premiums, price sets, discounts, etc.
