Glossary

app

As the term is used within Rattail Project documentation, this usually refers to a custom software application, built using Rattail, which runs on a server somewhere. Such an app may often be referred to with the name Poser, within the docs. An app may or may not be a web app for instance. Of course, “app” may also refer to any software application.

app model

The overall collection of models for the app. This is implemented as a Python module, which contains all the model classes in its namespace.

app node

A specific instance of an app which is part of a broader (i.e. multi-node) system.

batch

Can generally be thought of as a temporary or “workspace” table, with data which came from some source or other, and which the user may review and/or manipulate, before ultimately “executing” it, which in turn will update data within various systems, as appropriate. Note that the term “batch” primarily refers to the data itself, or the model instance representing it; see batch handler for the logic part.

See also

Data Batches

batch handler

Class or instance thereof, responsible for the “handling” logic for a certain type of batch. Generally each type of batch will have at least one “default” handler available, though more are possible. The batch handler knows how to populate, refresh and execute batches.

daemon

A software app or part thereof, which runs continually in the background. Examples are datasync and a web app.

datasync

Refers to a particular daemon whose responsibility is to “watch” various systems for data changes, and when any are found, cause various other systems to “consume” those changes. This is a configurable, multi-threaded app which spawns a separate thread for each datasync watcher, as well as a separate thread for each datasync consumer (per watcher).

datasync consumer

Class or instance thereof, responsible for “consuming” changes from a “watched” system within the datasync daemon. Any change coming from a datasync watcher is (potentially) then consumed by one or more other systems; each of which will use a separate consumer. May also refer to the specific thread spawned by the daemon to run the consumer logic.

datasync watcher

Class or instance thereof, responsible for “watching” a particular system for data changes, within the datasync daemon. May also refer to the specific thread spawned by the daemon to run the watcher logic. Changes found by the watcher are then processed by at least one datasync consumer.

import handler

Class or instance thereof, responsible for the “handling” logic for an overall import/export from one system to another. Primarily this is concerned with the “transaction” (e.g. database connections) and rollback/commit for the systems involved, where applicable. Each handler will contain at least one importer although most have more.

importer

Class or instance thereof, which contains logic for the import/export of data for one specific model, from one system to another. Note the difference between an importer and an import handler. Whereas the handler is responsible for the overall “transaction” between the two systems, the importer is responsible only for a single table, conceptually. In casual discussion, the term “importer” may sometimes be thrown around a bit more loosely, and e.g. refer to the system-level processes. But within the code proper, the term “importer” always will imply a particular data model association.

See also

Data Importers

model

Depending on context, this generally refers to a data table which is mapped to a class via the SQLAlchemy ORM. But it can also refer to the overall collection of such models (e.g. the app model).

model title

Singular title string for a given model (e.g. “Product”). See also plural model title.

plural model title

Plural title string for a given model (e.g. “Products”). See also model title.

Poser

The “stand-in” name for a custom app built using Rattail. No actual app should ever be named Poser! When you see the name Poser, you should mentally and literally replace it with whatever other name you chose to give your app.

system

This is mostly used generically, to represent various software applications and/or devices etc. with which the app must interact. However sometimes the app itself may be referred to as a system, for instance.

web app

An app which runs in a web browser, from the user’s perspective.