38 lines
1.2 KiB
ReStructuredText
38 lines
1.2 KiB
ReStructuredText
|
|
||
|
|
Concepts
|
||
|
|
========
|
||
|
|
|
||
|
|
.. _import-vs-export:
|
||
|
|
|
||
|
|
Import vs. Export
|
||
|
|
-----------------
|
||
|
|
|
||
|
|
From the framework's perspective, everything is actually an "import"
|
||
|
|
and never an "export" per se, i.e. data always flows from a source and
|
||
|
|
to a destination - or in other words, the "local" side always
|
||
|
|
*imports* from the "host" side. But see :doc:`exporting` for more
|
||
|
|
about that.
|
||
|
|
|
||
|
|
.. _importer-vs-import-handler:
|
||
|
|
|
||
|
|
Importer vs. Import Handler
|
||
|
|
---------------------------
|
||
|
|
|
||
|
|
All import (and export) tasks are accomplished by way of 2 things:
|
||
|
|
|
||
|
|
The "importer" is responsible for reading data from one place and
|
||
|
|
writing it to another place. But it cannot run itself, it just
|
||
|
|
contains the e.g. table-specific read/write logic.
|
||
|
|
|
||
|
|
The "import handler" is responsible for running one or more importers.
|
||
|
|
It also is (usually) responsible for "transaction-level" logic, e.g.
|
||
|
|
connecting to a database, and ultimately committing that transaction.
|
||
|
|
It usually has no table-specific logic, as that is the importer's job.
|
||
|
|
|
||
|
|
For instance you might want to import all customers and products from
|
||
|
|
your POS into Rattail; this would require something like:
|
||
|
|
|
||
|
|
* import handler for POS -> Rattail
|
||
|
|
* importer for Customer data
|
||
|
|
* importer for Product data
|