linotp.model package

This file contains the database definition / database model for linotp objects

wrt. the column name limitations see:

http://www.gplivna.eu/papers/naming_conventions.htm

Common rules 1. Only letters, numbers, and the underscore are allowed in names. Although

Oracle allows $ and #, they are not necessary and may cause unexpected problems.

  1. All names are in UPPERCASE. Or at least of no importance which case.

    Ignoring this rule usually leads referencing to tables and columns very clumsy because all names must be included in double quotes.

  2. The first character in the name must be letter.

  3. Keep the names meaningful, but in the same time don’t use

    long_names_describing_every_single_detail_of_particular_object.

linotp.model.create_admin_realm(admin_realm_name, admin_resolver_name)

create the default managed admin realm

linotp.model.create_admin_resolver(admin_resolver_name)

create the default managed admin resolver

to ease the programming, we work on an sql query result

linotp.model.fix_db_encoding(app) → None

Fix the python2+mysql iso8859 encoding by conversion to utf-8.

linotp.model.init_db_tables(app, drop_data=False, add_defaults=True)

Initialise LinOTP database tables.

This function initialises the LinOTP tables given an empty database (it also works if the database isn’t empty).

Parameters

  • drop_data – If True, all data will be cleared. Use with caution!

  • add_defaults – Adds default configuration variables if True. Don’t set this to False unless you know what you are doing.

linotp.model.set_defaults(app)

add linotp default config settings

Returns

  • nothing -

linotp.model.setup_db(app) → None

Set up the database for LinOTP.

This method is used to set up a SQLAlchemy database engine for the main LinOTP database. It does NOT generate a table structure if the database doesn’t have one (see init_db_tables() below for that).

This method is called during create_app(), which means that it happens pretty much always (during CLI commands and also when running from a WSGI application server), even before our own code really gets control. This is a hassle because we want to make sure that the database is properly initialised before going on our merry way, except when we know the database isn’t properly initialised and the next thing we’re about to do is to initialise it. This is why we have the revolting app.cli_cmd mechanism that is used below. It lets us skip the database setup when we’re doing linotp init or linotp config, both of which don’t touch the database, except for linotp init database, which skips the database setup during create_app() but then comes back to it in its own code after deviously setting app.cli_cmd to init-database so it goes into the if below after all. But in this case we still need to make an exception for it when it doesn’t find the Config table, because rather than croak with a fatal error we want to create the Config table.

FIXME: This is not how we would do this in Flask. We want to rewrite it once we get Flask-SQLAlchemy and Flask-Migrate working properly.

Submodules