1,126
edits
m (Added quote, tweaked text.) |
(Added a section on choosing the Load Expiration type.) |
||
| Line 99: | Line 99: | ||
=== Group reports in chronological order === | === Group reports in chronological order === | ||
Due to the way table segmentation works in OnDemand, you'll want to load the data in chronological order. When you name files, consider including a date field in YYYY-MM-DD format, so it can be sorted numerically at load time. This ensures that when the production server goes live, that end users will get speedy and fast database queries. | Due to the way table segmentation works in OnDemand, you'll want to load the data in chronological order. When you name files, consider including a date field in YYYY-MM-DD format, so it can be sorted numerically at load time. This ensures that when the production server goes live, that end users will get speedy and fast database queries. | ||
=== Use Expiration Type of "Load" === | |||
In Content Manager OnDemand, there are three options for expiring data loaded into Application Groups: | |||
;Document: examines each row of metadata to determine if it's eligible for expiration, and deletes individual rows from the database | |||
;Load: examines the arsload table to find loads in which ALL documents are eligible for expiration, and preforms an 'unload' | |||
;Segment: examines each database table (also know as a "Segment") to determine if ALL the documents in the table are eligible, then it simply drops the database table. | |||
For historical migrations, using the 'Load' expiration types, minimizing the date range inside a single load file, and loading in chronological order will prevent issues with the deletion or disposition of data in the future. | |||
=== Name output files in AG.Date.App format === | === Name output files in AG.Date.App format === | ||