45 lines
1.8 KiB
ReStructuredText
45 lines
1.8 KiB
ReStructuredText
|
|
||
|
|
Merging
|
||
|
|
=======
|
||
|
|
|
||
|
|
Rattail ostensibly supports merging any 2 records, of any kind. But
|
||
|
|
the devil is always in the details...
|
||
|
|
|
||
|
|
In most cases a merge involves:
|
||
|
|
|
||
|
|
* inspect differences between 2 records
|
||
|
|
* choose which one to "keep" vs. "remove"
|
||
|
|
* perform the merge, which:
|
||
|
|
|
||
|
|
* may *update* the "keep" record, with certain data from the "remove" record
|
||
|
|
* then *deletes* the "remove" record
|
||
|
|
|
||
|
|
For some things this can be pretty straightforward, for instance if
|
||
|
|
your User records are maintained only in Rattail and aren't imported
|
||
|
|
from elsewhere, then a merge of 2 User records could by definition
|
||
|
|
only affect Rattail anyway.
|
||
|
|
|
||
|
|
Although even that example can be tricky, because a User is often
|
||
|
|
involved in some audit trail(s) of various other data records. In
|
||
|
|
such cases Rattail can update the historical records to reflect the
|
||
|
|
new "keep" User record; but in practice there may be edge cases as yet
|
||
|
|
unexplored.
|
||
|
|
|
||
|
|
Customer and Employee records etc. can present more of a challenge,
|
||
|
|
because often that data lives in multiple systems. The question
|
||
|
|
becomes, what should a merge actually *do*, i.e. what should the
|
||
|
|
ideal outcome be?
|
||
|
|
|
||
|
|
In particular your POS may have 2 customer records which you'd like to
|
||
|
|
merge, but even if your ideal outcome is for one of them to be deleted
|
||
|
|
(i.e. typical use case described above), the problem of historical
|
||
|
|
data may come up again. Often times both of the customer records will
|
||
|
|
already have accrued some transaction history within your POS, and it
|
||
|
|
may not be possible or practical to correct those with the new
|
||
|
|
("keep") customer reference.
|
||
|
|
|
||
|
|
But the merge tool is meant to be as flexible as is reasonable. Your
|
||
|
|
merge logic might be able to go ahead with certain "simple" merges but
|
||
|
|
then raise an error when complex situations are encountered. Then you
|
||
|
|
can look more closely at those and see what can be done (if anything).
|