When requesting disco info on a bare jid which is not in our roster, server may return
"Service Unavailable" (to avoid leaking valid JIDs). In this case, the initiation was
failing, this is now fixed by using empty categories in this case.
When a "Unable to guess signature […]" `ValueError` is raised during a method call, the
signatures are re-introspected. This should fix this issue when a frontend is launched
just after to the backend (this happens notably with tests).
SQLite specific behaviour with autoincrement (https://sqlite.org/autoinc.html) is actually
already handled by SQLAlchemy, and unsetting autoincrement cause troubles when storing new
objects.
The `LIBERVIA_BRIDGE_NAME` environment variable can now be used to specify the bridge to
use. If set and different from empty string, the environment has precedence over config
file value.
For `pb` bridge, the following environment variable can also be used:
- LIBERVIA_BRIDGE_PB_CONNECTION_TYPE
- LIBERVIA_BRIDGE_PB_HOST
- LIBERVIA_BRIDGE_PB_PORT
When text syntaxes was initialised, `syntaxes` dict was filled, but it was a class
attribute. As a result, re-initialising it (which may happen for tests, and maybe in the
future dynamically), was not starting with an empty dict, but with an already-filled one,
resulting in conflicts.
This patch fixes it by moving `syntaxes` to an instance attribute.
- arguments don't need to be encoded anymore, `spawnProcess` handles str directly now
- use full path even for first argument: even if first argument should be only executable
name, it appears that using full path only in `command` is not enough (seen with Python
where system installation is used instead of the VirtualEnv one when full path is not
used as first argument).
a first Alembic revision file is joined to migrate existing databases to new mapping.
This patch:
- set `nullable=False` in various places
- drop legacy `message_types` table, and use `Enum` instead
- use naming convention, and get rid of anonymous constraint (this is the main reason
why the revision file is so long)
Alembic database migration tool, which is the recommended one for SQLAlchemy has been
integrated. When a database is created, it will be used to stamp to current (head)
revision, otherwise, DB will be checked to see if it needs to be updated, and upgrade will
be triggered if necessary.