If the target of the Reference field is deleted, the transaction cache is not
cleared because there is no "ON DELETE" support for Reference field. Instead
the ids are checked in the Reference.get method.
Closes#12599
For table renamed before baa87cf1a343, we must keep renaming existing sequence
because the migration to identity expect that the sequences include the table
name.
Closes#12245
Since 0db956eb2505 _changed_value is used for on_change_with calls, so it can
have to deal with unsaved Many2One value if it is the parent of a One2Many.
Applying the domain on the LEFT JOIN create wrong result because the fallback
value (from COALESCE) is then used even if a valid translation exists.
Closes#11781
Without the size the TableHandler creates a schema without size. When the
schema is updated, it raises a warning because it can not resize from no size.
Also even if SQLite does not enforce the size of the schema, at least we have
a correct schema.
Closes#12471
When deleting a full branch of a tree, if the number of records deleted is
higher than IN_MAX, the foreign key constraint may prevent the deletion
because the group of records deleted may still be referencing a record in the
next group to delete.
To prevent this failure, we must first clean the values of the column with
foreign key referencing the same table. We use the table id as value instead
of NULL in case the column is not nullable.
When a connection in the pool is disconnected, it stays in the pool and it may
still be served.
Using such connection raise an OperationalError and so the request is retried
but before that the connection is put back to the pool. So we may get it back
again.
It is not possible to distinct between an OperationalError due to a
disconnection or due to a isolation error for example.
So with the current design of Transaction API, an OperationalError always put
back the connection to the pool.
This main that we can only ensure that the connections served are still
connected by executing a simple query. And close connections that are failing.
Closes#12452
In this changeset we fix an issue with testing.
When using the listener for cache invalidation it results into the database
lock used by the pool that is acquired twice. Once when calling Pool.init ;
once when the transaction is started which calls Cache.sync which in turn calls
Pool.refresh and finaly Pool.stop. It tries to acquire again the re-entrant
lock (but it cannot because it's another thread).
Closes#12457
Cédric Krier