[server] Make "sources_by_uri" and "sources_by_eid" properties of repository
I.e. do not populate these dict as repo initialization (bootstrap step) but
always use information from database. This is needed because when multiple
instances of the same application run, if one instance adds a CWSource the
other ones will not see it. In particular, when using a scheduler instance,
new CWSource will be added by the web instance and not seen by the scheduler
which is supposed to update them.
We thus define properties for sources_by_eid and sources_by_uri instead
attributes on repository instance. CWSource entities are thus retrieved from
database every time these properties are accessed. We factor out
initialization of the "source" instance (subclass of
cubicweb.server.source.AbstractSource) in a _sources() method. Note that this
method takes care of calling "init" method on the source as well as
"set_schema" (previously done in repo.set_schema(), which now only touches
system_source). Accordingly the "init_sources_from_database" method is dropped
along with "add_source"/"remove_source" methods.
In syncsources hook, we thus drop:
* SourceAddedOp operation which called repo.add_source() so that the
SourceAddedHook only cares about checking source configuration now;
* SourceRemovedOp and SourceRenamedOp operations for the same reason;
* SourceConfigUpdatedOp as updating the live config of source is
meaningless once we rely on them being retrieved from the database;
* SourceHostConfigUpdatedHook hook which is now useless without call to
SourceConfigUpdatedOp;
In 3.10 migration script, remove usage of sources_by_uri repo attribute which,
unless I'm missing something, appears useless (at least now).
In tests:
* unittest_datafeed: remove test_update_url method since we dropped respective
hook;
* unittest_ldapsource: LDAPFeedUserDeletionTC.test_a_filter_inactivate()
currently fails because it still relies on live config being updated, this
will be fixed in the next changeset once all "live source" logic will be
removed.
.. -*- coding: utf-8 -*-
.. _cubicweb-ctl:
``cubicweb-ctl`` tool
=====================
`cubicweb-ctl` is the swiss knife to manage *CubicWeb* instances.
The general syntax is ::
cubicweb-ctl <command> [options command] <arguments commands>
To view available commands ::
cubicweb-ctl
cubicweb-ctl --help
Please note that the commands available depends on the *CubicWeb* packages
and cubes that have been installed.
To view the help menu on specific command ::
cubicweb-ctl <command> --help
Listing available cubes and instance
-------------------------------------
* ``list``, provides a list of the available configuration, cubes
and instances.
Creation of a new cube
-----------------------
Create your new cube cube ::
cubicweb-ctl newcube -d <target directory>
This will create a new cube ``<target directory>``.
Create an instance
-------------------
You must ensure `~/etc/cubicweb.d/` exists prior to this. On windows, the
'~' part will probably expand to 'Documents and Settings/user'.
To create an instance from an existing cube, execute the following
command ::
cubicweb-ctl create <cube_name> <instance_name>
This command will create the configuration files of an instance in
``~/etc/cubicweb.d/<instance_name>``.
The tool ``cubicweb-ctl`` executes the command ``db-create`` and
``db-init`` when you run ``create`` so that you can complete an
instance creation in a single command. But of course it is possible
to issue these separate commands separately, at a later stage.
Command to create/initialize an instance database
-------------------------------------------------
* ``db-create``, creates the system database of an instance (tables and
extensions only)
* ``db-init``, initializes the system database of an instance
(schema, groups, users, workflows...)
Commands to control instances
-----------------------------
* ``start``, starts one or more or all instances
of special interest::
start -D
will start in debug mode (under windows, starting without -D will not
work; you need instead to setup your instance as a service).
* ``stop``, stops one or more or all instances
* ``restart``, restarts one or more or all instances
* ``status``, returns the status of the instance(s)
Commands to maintain instances
------------------------------
* ``upgrade``, launches the existing instances migration when a new version
of *CubicWeb* or the cubes installed is available
* ``shell``, opens a (Python based) migration shell for manual maintenance of the instance
* ``db-dump``, creates a dump of the system database
* ``db-restore``, restores a dump of the system database
* ``db-check``, checks data integrity of an instance. If the automatic correction
is activated, it is recommanded to create a dump before this operation.
* ``schema-sync``, synchronizes the persistent schema of an instance with
the instance schema. It is recommanded to create a dump before this operation.
Commands to maintain i18n catalogs
----------------------------------
* ``i18ncubicweb``, regenerates messages catalogs of the *CubicWeb* library
* ``i18ncube``, regenerates the messages catalogs of a cube
* ``i18ninstance``, recompiles the messages catalogs of an instance.
This is automatically done while upgrading.
See also chapter :ref:`internationalization`.
Other commands
--------------
* ``delete``, deletes an instance (configuration files and database)