Demo fixtures

A fixture, in Django, is a portion of data (a collection of data records in one or several tables) which can be loaded into a database.

fixtures

Fixtures are defined by the files in so-called fixtures directories. When a plugin has a subpackage named fixtures, Django will discover this package when you run the loaddata command. This is standard Django knowledge. Read more about it in the Django documentation.

Lino uses this to define the concept of demo fixtures. These are a predefined set of fixture names to be specified by the application developer in the demo_fixtures attribute. The min1 application has the following value for this attribute:

>>> from lino import startup
>>> startup('lino_book.projects.min1.settings')
>>> from django.conf import settings
>>> settings.SITE.demo_fixtures
'std demo demo2'

This means that the pm prep command (in a lino_book.projects.min1 application) is equivalent to:

$ python manage.py initdb std demo demo2

The difference between initdb and pm prep is that with pm prep, you don't need to know the list of demo fixtures when invoking the command. The default list of demo fixtures to load for initializing a "clean" standard demo database can be long and difficult to remember, and (more importantly) which can change when an application evolves. System administrators usually don't want to know such details. As a future application developer you can learn more about them in Writing Python fixtures.

Note that in Lino we usually don't write fixtures in XML or JSON but write them in Python.

The loading phases of demo fixtures

We suggest to see each fixture name as a loading phase. It is up to the application developer to specify a meaningful set of loading phases in the demo_fixtures setting.

Our convention is to define the following loading phases:

std minimal_ledger demo demo_bookings payments demo2 demo3 checkdata

std minimal_ledger demo demo_bookings payments demo2 demo3 checkdata

The loading order of demo data is important because the fixtures of the Lino Extensions Library are inter-dependent. They create users, cities, journals, contacts, invoices, payments, reports, notifications, ... you cannot write invoices if you have no customers, and an accounting report makes no sense if bank statements haven't been entered.

Lino basically uses Django's approach of finding demo fixtures: When Django gets a series of fixture names to load, it will load them in the specified order, and for each fixture will ask each plugin to load that fixture. If a plugin doesn't define a fixture of that name, it simply does nothing.

The demo_fixtures setting is a string with a space-separated list of fixture names to be loaded by pm prep.

std

The std fixtures should add default database content expected to be in a virgin database even when no "demo data" is requested. This should always be the first fixture of your demo_fixtures setting. It is provided by the following plugins:

minimal_ledger

Add minimal config data. Should come after std and before demo.

demo

Adds master demo data.

demo_bookings

Adds more demo data (originally "bookings"). Should come after demo.

  • lino_xl.lib.invoicing creates monthly invoicing plans and executes them. Starts a January 1st of lino_xl.lib.ledger.Plugin.start_year. Stops 2 months before today (we "forgot" to run invoicing the last two months) because we want to have something in our invoicing plan.

  • lino_xl.lib.ledger Creates fictive monthly purchase invoices. For some of them it creates a dummy upload file that represents the source document.

  • lino_xl.lib.sales creates fictive monthly sales.

payments

Adds even more demo data (originally "payments"). Should come after demo_bookings.

  • lino_xl.lib.bevat creates a Belgian VAT office and some VAT declarations.

  • lino_xl.lib.bevats creates a Belgian VAT office and some VAT declarations.

  • lino_xl.lib.eevat creates an Estonian VAT office and some VAT declarations.

  • lino_xl.lib.finan creates automatic monthly payment orders and bank statements. Bank statements of last month are not yet entered into database

demo2

Add final demo data.

demo3

  • lino.modlib.uploads creates an orphan file foo.pdf in uploads folder and removes the file of one first upload entry to simulate some data issues to detect by checkdata.

checkdata

Should come after demo2.

This fixture should always be the last in your demo_fixtures setting.