Consultor Eletrônico

Status: Unverified

GOAL:

Considerations about CRC

GOAL:

How do the CRC work?

FACT(s) (Environment):

Progress 9.x
OpenEdge 10.x

FIX:

The following changes to CRCs were introduced since Progress Version 9.x.
1. Index definitions are not part of a table's CRC anymore.
If a new index is created on a table, the table crc will not change.
If an index is deleted, the table's crc will not change.

An application may not work anymore if the index it was using is deleted it, but adding a new index will not cause a recompile to be needed.
On the other hand, the application will not know about the new index unless it uses dynamic queries. If it uses dynamic queries, it can take advantage of a new index immediately, without recompiling anything.

2. Indexes have their own crc.
Changing an index definition will cause its crc to change, and that will require a recompile.

3.Table's logical column layout are separated from its underlying physical layout.
A table's crc is computed on the logical column layout rather than on the physical layout.

This has the following benefits:
* When a schema change to a table is made, the data stored in the database doesn't need to be changed right away. This means that schema changes can be performed quickly independent of the amount of data stored in a table. The transactions that update the schema can be very small and fast.

* Since the crc is on the logical column layout, it does not matter how the logical column layout became different from the physical layout. The crc can be the same no matter what order incremental schema change operations are performed, as long as the data types and logical positions match at the end.

4. All the relevant information is dumped to .df files. In particular, a field's record position (rpos) is dumped, and can be set on a load as long as there are no conflicts - like two fields with the same position.

5. When an incremental .df is generated by the user, changes to the logical position are dumped.

To illustrate how this works, consider the following sequence of schema changes.

1. Make a copy of the sports database and call it sports1.
The initial crc of the customer table is 48132.

2. Delete the address field of the customer table.
The customer table crc is now 65021.

3. Add a new address field which ends up at position 18 in the customer record.
The customer crc becomes 631.

4. Do an incremental dump and produce delta.df1.

5. Create a new copy of the sports database in sports2.
The crc of the customer table is 48132, as before in step 1.

6. Apply the incremental delta.df1 to sports2.
The customer crc is now 631, same as in step 3.

7. Now go back to sports1 and add a new integer field new1 to sports1.

8. Generate a new incremental dump delta.df2. It contains an add for new1.

9. Add another new field new2, character, to sports1.

10. Generate a new incremental dump, delta.df3, which contains an add for new1 and for new2.
At this point, the crc for the customer table has become 37584. Four changes have been made from the original sports: delete original address field, add address field, add field new1, add field new2.

11. Now go back to sports2 and apply the incremental df delta.df3.
The customer crc is 37584.
No surprise here, because two incrementals were applied, delta.df1 and delta.df3.

12. Now create a new database sports3 from the original unmodified sports.
The customer table crc is 65021.

13. Apply delta.df2, which adds new1 to sports3.
The customer .table crc is 18162.

14. Delete the field new1, which just got added.
The crc is 48132.

15. Apply delta.df3, which adds fields new1 and new2.
The crc is now 19672.

16. Apply delta.df1, which updates the position of the field address to sports3.
The customer crc is now 37584.

This is exactly the same value than for sports2 in step 11 above.
But the order in which the changes were applied to sports2 and sports3 was different.

For sports2, delta.df1 and delta.df3 were applied.

For sports3, delta.df2 was applied, updated the schema to delete the field it added, then applied delta.df3, and then delta.df1..