| 195 | == Processing Considerations |
| 196 | |
| 197 | - When processing using cron, the request that processes the cron will be much slower. Therefore, we need to process as little as possible in the cron job and break up the large imports into smaller imports. |
| 198 | - Queued jobs are run from within a cron job, so that doesn't really gain us anything. |
| 199 | - The onyx table {{{action}}} contains a list of start and stop editing actions against different interviews. The participant id can be obtained by looking in the interview table with the interview id from the action table. |
| 200 | - Therefore, it should be possible to identify which participants have changed since the last date processed. Or rather since the date of the last action processed. |
| 201 | |
| 202 | The process can therefore look something like this: |
| 203 | |
| 204 | 1. Run a query in Onyx that returns a list of participants details. |
| 205 | 1. The details should contain the date/time of the most-recent action related to an interview for that participant, {{{participant_most_recent_action_date}}}. |
| 206 | 1. The query should be filtered to not return participant details whose most recent action occurred before the most recent action processed by the system. '''NB: Not the date that the processing occurred, but the date of the participant's {{{participant_most_recent_action_date}}}''' |
| 207 | 1. The query should be filtered to return only as many participant details as can be processed in a time that will not unduly affect the performance of the request in which the processing occurs. |
| 208 | 1. The query results should be ordered by {{{participant_most_recent_action_date}}} ascending. |
| 209 | 1. The details should be processed. |
| 210 | 1. The {{{participant_most_recent_action_date}}} for the final participant should be recorded in a variable. ''Are Drupal Variables persistent when the server is restarted?'' |