...
Time | Item | Who | Notes | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
Optimistic locking workarounds | Jeff (Duke): Adding automatic updates and corrections for optimistic locking errors. Doing daily incremental updates. It tries to double-check the optimistic locking (looks up the version number) and updating the version number when he sends it in. But sometimes updates twice (bound-withs!!!), and so errors. Looks again for version number and sends again. Going for batch apis first. When doing the error correction, does each record individually and looks up version number first. Relevant Jiras
What error response do we want? | |||||||||||
Migration status/checkin
For settings, have gitlab with settings in it with UUIDs (Jeff’s script loads the settings) For any of the automated data, use type 5 UUID generation so they are the same all the time. Orders: Jeff doing open, and limited closed orders because see performance issues if number to migrate gets too big. ~15K open orders. Tod: mod-orders needed more memory (4G RAM) when doing FY rollover (it has memory leak?). Closed orders are also rolling with zero encumbrances (they’re going to fix this). Dry runs were really important, were able to fix small number of errors manually. | WOLFcon sessions |
We discussed that we should cancel the Data Migration Workshop, for 2 reasons | ||||||||||