runtime Subpackage

runtime Package

Runtime

This subpackage provides encapsulations and entry points for the application itself:

• the session module features the supporting objects for “Odoo scripts” and the dedicated python interpreter.

• the start_odoo and test_odoo modules are the entry points for the main startup scripts.

This architecture is meant in particular to provide stability and uniformity accross Odoo major versions, so that the recipe can be leveraged by automated deploymnent tools and continuous integration systems.

oca.recipe.odoo.runtime.already_imported(module_name)

Convenience to help some Odoo modules to avoid been imported twice.

Each call of this function returns a boolean indicated whether the specified module was already in the imported_addons registry and add it inconditionnally.

Thus caller code is expected to import the module right away if the return value was False.

oca.recipe.odoo.runtime.clear_import_registry()

session Module

Utilities to start a server process.

class oca.recipe.odoo.runtime.session.OdooVersion(vstring=None)

Bases: Version

Odoo idea of version, wrapped in a class.

This is based on odoo.tools.parse_version(), and Provides straight-ahead comparison with tuples of integers, or distutils Version classes.

parse(incoming)

class oca.recipe.odoo.runtime.session.Session(conffile, buildout_dir, parse_config=True)

Bases: object

A class to give server-level access to one database.

There should be exactly one instance of this class per process. It can be used for any kind of script involving Odoo API, and provides facilities for upgrade scripts (see also :mod:oca.recipe.odoo.runtime.upgrade)

Before actual use, call open(). Then you’ll have useful attributes and methods reminiscent of the unit test classes:

• cr: a cursor

• uid: user id

• registry: access to model objects

• is_initialization: True if and only if the database was not initialized before the call to open()

Example application code:

session.open(db_name="my_db")
admin = session.registry('res_users').browse(session.cr, session.uid, 1)
(...)
session.cr.commit()
session.close()

Transaction management is up to user code

Upgrade scripts writers should check the version handling properties:

• db_version()

• package_version()

Instantiation is done by passing the path to Odoo main configuration file and the path of the buildout directory.

Usually, instantiation code is written by the recipe in the body of the executable “Odoo scripts” it produces. Script writers provide a callable that takes a Session object argument and declare it as a console script entry point in their distribution. End users can reference such entry points in their buildout configurations to have buildout produce the actual executable. See Odoo Scripts for details.

Upgrade scripts are a special case of that process, in which the entry point is actually provided by the recipe and rewraps a user-level source script.

Later versions of the recipe may find a way to pass the whole buildout configuration (recall that this is to be used in a separate process in which the buildout configuration has not been parsed).

browse_ref(external_id)

Return ir.model.data browse object from its external identifier.

Parameters:

external_id – External identifier of form module.name. e.g. base.user_root

Raise:

ValueError if not found or external_id malformed

clean_environments(reinit=True)

Cleans the thread-local environment.

See init_environments() for more details. This method does nothing if the environments have not been initialized.

Parameters:

reinit (bool) – if True, init_environments() will be called again after cleaning

close()

Close the cursor and forget about the current database.

The session is thus ready to open another database. This methods should be idempotent, wouldn’t fail if the cursor is already closed or the current database is not in registry (either already deleted, or could not be opened at all)

property db_version

Settable property for version stored in DB of the whole buildout.

This can be thought as the latest version to which the DB has been upgraded to. A simple caching system to avoid querying the DB multiple times is implemented.

handle_command_line_options(to_handle)

Handle prescribed command line options and eat them.

Anything before first occurrence of -- on the command-line is taken into account and removed from sys.argv.

Help messages:

If -h or –help is specified and – is not, the help for the wrapper will be printed, and the -h/–help option kept in sys.argv.

If -h or –help is specified before –, the help for this wrapper will be printed and options after – will be kept in sys.argv.

if -h or –help is specified after –, it will be ignored at this stage, and kept in sys.argv (in most cases triggering help print for the wrapped script).

init_cursor()

init_environments()

Enter the environments context manager, but don’t leave it

Automatically called by open() and registry altering methods. See :class:odoo.api.Environment for explanations about environments.

This thread-local environments is initialized and cleaned with each request in the normal usage of the framework. That’s why is is provided as a context manager.

Therefore, user code probably needs in some case to clean it to avoid side effects. This can be done by calling clean_environments().

install_modules(modules, db=None, update_modules_list=True, open_with_demo=False)

Install the modules in the database.

Has the side effect of closing the current cursor, committing if and only if the list of modules is updated.

Demo data loading is handled consistently with the decision taken by open().

Parameters:

• db – Database name. If not specified, it is assumed to have already been opened with open(), e.g, for a prior read of db_version(). If it is specified, then the session in particular opens that db and will use it afterwards whether another one was already opened or not.

• modules – any iterable of module names.

• update_modules_list – if True, will update the module lists and commit before the install begins.

• open_with_demo – if db is not None, will be passed to open().

is_cursor_closed()

Compatibility wrapper.

On Odoo 7, the attribute is __closed but can’t even be accessed if the cursor is closed (OperationalError is raised systematically in sql_db)

On Odoo 8, the attribute is _closed and works correctly.

open(db=None, with_demo=False)

Load the database

Loading an empty database in Odoo has the side effect of installing the base module. Whether to loading demo data or not has therefore to be decided right away.

Parameters:

• db – database name. If not specified, the same cascading of defaults as Odoo mainstream will be applied: configuration file, psycopg2/lipq defaults.

• with_demo –

  controls the loading of demo data for all module installations triggered by this call to open() and further uses of load_modules() on this Session instance:

  • if True, demo data will uniformly be loaded

  • if False, no demo data will be loaded

  • if None, demo data will be loaded according to the value of without_demo in configuration

  In all cases, the behaviour will stay consistent until the next call of open(), but the implementation does not protect against any race conditions in Odoo internals.

property package_version

Property reading the version file from buildout directory.

Comments introduced with a hash are accepted. Only the first significant line is taken into account.

parse_version_string(vstring)

Stable method for downstream code needing to instantiate a version.

This method returns an appropriate version instance, without any dependency on where to import the class from. Especially useful for applications whose life started before this set of utilities has been used : this helps building an usable default.

ready()

ref(external_id)

Return ir.model.data object id from its external identifier.

Parameters:

external_id – External identifier of form module.name. e.g. base.user_root

Raise:

ValueError if not found or external_id malformed

registry(model)

Lookup model by name and return a ready-to-work instance to use the old api. However you must use session.env['model'] to get the instance in the new api (from version 8), this expect to raise in version 10

rollback()

update_modules(modules, db=None)

Update the prescribed modules in the database.

Parameters:

• db – Database name. If not specified, it is assumed to have already been opened with open(), e.g, for a prior read of db_version(). If it is specified, then the session in particular opens that db and will use it afterwards whether another one was already opened or not.

• modules – any iterable of module names. Not installed modules will be ignored The special name 'all' triggers the update of all installed modules.

update_modules_list()

Update the list of available Odoo modules, like the UI allows to.

This is necessary prior to install of any new module.

property version_file_path

Absolute path of the flat file storing the package version.

For now this is not configurable, a later version might read it from buildout configuration.

upgrade Module

Uniform encapsulation of buildout-local upgrade script.

The idea is to provide a common set of options, so that upgrade scripts all have the same interface, and project maintainers can focus on the decision taking logic.

oca.recipe.odoo.runtime.upgrade.upgrade(upgrade_script, upgrade_callable, conf, buildout_dir)

Run the upgrade from a source file.

All arguments are set in the standalone script produced by buildout through entry point options.

• upgrade_script: absolute path to the upgrade script python source.

• upgrade_callable: name of the callable in source file actually running the script.

  It must accept the two following positional arguments, in that order:

  • a Session instance (as in standard “Odoo scripts”)

  • a logger (standard object from the logging module)

  and may return a non zero status code to indicate an error. Both None and 0 are interpreted as success.

• conf: path to the Odoo configuration file (managed by the recipe)

• buildout_dir: directory of the buildout

start_openerp Module

This module bridges the classical openerp-server as a console script.

The main() function gets registered on the fly by the server recipe as a console script entry point and used in particular for start_odoo and test_odoo.

Some version independence logic for the startup process also get bootstrapped from here.

oca.recipe.odoo.runtime.start_odoo.insert_args(arguments)

Insert arguments in sys.argv (direct impact on child script).

oca.recipe.odoo.runtime.start_odoo.main(starter, conf, version=None, just_test=False, server_wide_modules=None, gevent_script_path=None)

Call the starter script, dispatching configuration.

All arguments are set in the standalone script produced by buildout through entry point options.

Parameters:

• starter – path to the main script source file (currently openerp-server)

• conf – path to the Odoo configuration file (managed by the recipe)

• version (tuple of integers) – Odoo major version

• server_wide_modules – additional server wide modules, to pass with the --load command-line option (ignored if the option is actually there on the command line)

• just_test – if True, only run unit tests

test_openerp Module

oca.recipe.odoo.runtime.test_odoo.insert_args(arguments)

oca.recipe.odoo.runtime.test_odoo.main(starter, conf, version=())