rattail/moin-archive-oldest
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Add ImplementationDetails

Lance Edgar 2025-10-19 07:45:40 -05:00
parent 57b956416e
commit 49120195fa
1 changed files with 24 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

24
ImplementationDetails.md Normal file

@ -0,0 +1,24 @@
# Implementation Details
Various common aspects of implementation are suggested and described below.
## ETL
Most likely it will be necessary to [[http://en.wikipedia.org/wiki/Extract,_transform,_load|ETL]] all available and relevant data from other systems. This will need to happen on a regular basis (typically nightly) for as long as the integration with or migration from the other system(s) lasts.
The ETL process will necessarily be quite custom for each organization, although it's possible that some common back-ends might be "supported" somewhat over time. Most of the objects will require a custom "key" (mapped to the class via a [[http://packages.python.org/Rattail/extensions.html|Rattail extension]]) for the sake of tracking the object between ETL jobs. For example, since our other system is CAM32, I'll map a field called `cam32_key` (with a unique constraint) to the Product class. Prior to creating a new Product within Rattail during the ETL job, I'll first search Rattail for a Product which contains the `cam32_key` in question. If found then that Product will be updated; if not then a new one is created and its `cam32_key` is assigned.
### Customers
When ETLing *new* customer data, the transformation step could be somewhat heavier. Since Rattail supports associating more than one Person with a Customer, and since most other systems probably assume a "Customer" *is* a single "Person", the process will be to:
1. Create a Person.
1. Attach contact info to the Person.
1. Attach the Person to a new Customer.
1. Assign the custom key on the Customer for object tracking.
On the other hand, the other system might also have the notion that a Customer may include more than one Person, in which case the mapping should be more or less direct.
### Prices
The Price class will not need a custom key field, as its uniqueness may be determined by its `product`, `level`, and `amount` attributes. When a price change for a previously-ETLed Product occurs between consecutive ETL jobs, the old "current" `Price.expires` is set to the current date, and a new Price is created with `expires` set to `None`, so as to make it current.