Glossary¶

ad hoc script¶

Python script (text) file used for ad-hoc automation etc. See also Ad Hoc Scripts.

app¶

Depending on context, may refer to the software application overall, or the app name, or the app handler.

app database¶

The main database used by the app. There is normally just one database (for simple apps) which uses PostgreSQL for the backend. The app database contains the settings table as well as data models.

For more info see App Database.

app dir¶

Folder containing app-specific config files, log files, etc. Usually this is named app and is located at the root of the virtual environment.

Can be retrieved via get_appdir().

app enum¶

Python module whose namespace contains all the “enum” values used by the app. Available on the app handler as enum.

app handler¶

Python object representing the core handler for the app. There is normally just one “global” app handler; see also App Handler.

app model¶

Python module whose namespace contains all the data models used by the app.

app name¶

This refers to the canonical name for the underlying app/config system. It does not refer to the overall app; contrast with app title.

In most cases (i.e. by default) this will simply be wutta. This value affects the naming conventions for config files as well as setting names etc.

The primary reason for this abstraction is so that the Rattail Project could leverage the Wutta config logic without having to rewrite all config files in the wild.

See also AuthHandler.

batch¶

This refers to a process whereby bulk data operations may be performed, with preview and other tools to allow the user to refine as needed before “executing” the batch.

The term “batch” may refer to such a feature overall, or the data model used, or the specific data for a single batch, etc.

See also batch handler and batch row, and the BatchMixin base class.

batch handler¶

This refers to a handler meant to process a given type of batch.

There may be multiple handlers registered for a given batch type, but (usually) only one will be configured for use.

batch row¶

A row of data within a batch.

May also refer to the data model class used for such a row.

See also the BatchRowMixin base class.

batch type¶

This term is used to distinguish batches according to which underlying table is used to store their data, essentially.

For instance a “pricing batch” would use one table, whereas an “inventory batch” would use another. And each “type” would be managed by its own batch handler.

The batch type is set on the model class but is also available on the handler:

command¶

A top-level command line interface for the app. Note that top-level commands don’t usually “do” anything per se, and are mostly a way to group subcommands. See also Command Line.

config¶

Depending on context, may refer to any of: config file, config object, config setting. See also Configuration.

config extension¶

A registered extension for the config object. What happens is, a config object is created and then extended by each of the registered config extensions.

The intention is that all config extensions will have been applied before the app handler is created.

config file¶

A file which contains config settings. See also Config Files.

config object¶

Python object representing the full set of config settings for the app. Usually it gets some of the settings from config files, but it may also get some from the settings table. See also Config Object.

config setting¶

The value of a setting as obtained from a config object. Depending on context, sometimes this refers specifically to values obtained from the settings table as opposed to config file. See also Config Settings.

data model¶

Usually, a Python class which maps to a database table.

The app (assuming it has an app database) will have an “official” set of data models, represented as the app model.

database¶

Generally refers to a relational database which may be queried using SQL. More specifically, one supported by SQLAlchemy.

Most apps will have at least one app database. See also Databases.

db handler¶

The handler responsible for various operations involving the app database (and possibly other databases).

See also the DatabaseHandler base class.

db session¶

The “session” is a SQLAlchemy abstraction for an open database connection, essentially.

In practice this generally refers to a Session instance.

email handler¶

The handler responsible for sending email on behalf of the app.

Default is EmailHandler.

email key¶

String idenfier for a certain email type. Each email key must be unique across the app, so the correct template files and other settings are used when sending etc.

email module¶

This refers to a Python module which contains email setting definitions.

email setting¶

This refers to the settings for a particular email type, i.e. its sender and recipients, subject etc. So each email type has a “collection” of settings, and that collection is referred to simply as an “email setting” in the singular.

email template¶

Usually this refers to the HTML or TXT template file, used to render the message body when sending an email.

email type¶

The app is capable of sending many types of emails, e.g. daily reports, alerts of various kinds etc. Each “type” of email then will have its own template(s) and sender/recipient settings etc. See also email key.

entry point¶

This refers to a “setuptools-style” entry point specifically, which is a mechanism used to register “plugins” and the like. This lets the app / config discover features dynamically. Most notably used to register commands and subcommands.

For more info see the Python Packaging User Guide.

handler¶

Similar to a “plugin” concept but only one handler may be used for a given purpose. See also Handlers.

install handler¶

The handler responsible for installing a new instance of the app.

Default is InstallHandler.

package¶

Generally refers to a proper Python package, i.e. a collection of modules etc. which is installed via pip. See also Package Installation.

provider¶

Python object which “provides” extra functionality to some portion of the app. Similar to a “plugin” concept; see Providers.

settings table¶

Table in the app database which is used to store config settings. See also Settings Table.

spec¶

As the term is used in Wutta Project context, this refers to a string designating the import path to a particular object (class, function etc.).

Also the term implies a certain format, namely a dotted module path followed by colon (:), then object name.

For instance, wuttjamaican.app:AppHandler is the spec string for the wuttjamaican.app.AppHandler class (and note, the hyperlink does not use colon, but our “spec” always does).

See also load_object() (on the app handler) which can return any object from spec.

subcommand¶

A top-level command may expose one or more subcommands, for the overall command line interface. Subcommands are usually the real workhorse; each can perform a different function with a custom arg set. See also Command Line.

virtual environment¶

This term comes from the broader Python world and refers to an isolated way to install packages. See also Virtual Environment.