Database.update() may change tables in the databases passed to the function

[frankenjoe]

As pointed out by @hagenw in #467 (comment) it is possible that a call to Database.update() changes the tables in the databases that are passed to the function. This is probably caused by this line.

Since this is not an expected behavior we should at least document it.

[hagenw]

The line is using other_table.extend_index(index, inplace=True) so we should maybe avoid using inplace=True. I guess we selected this solution to not have to copy very large tables to another place in memory. But maybe there is another solution?
One hacky one would be to first extend the index and in the end remove the extended entries.

[frankenjoe]

As far as I see, in this for loop the tables are only prepared for joining them later. I.e. if we use inplace=False the statement had no affect and joining the tables later would probably not work as expected.

[hagenw]

This issue affects only misc tables that are used as labels for a scheme.

But this also means it will be not so easy to change, as for updating databases we rely on them having the same schemes labels. Also for the case where the labels are not stored in a misc table we do the following at the moment:

audformat/audformat/core/database.py

Line 1222 in 2872a9a

utils.join_schemes([self, other], scheme_id)

Which will modify the scheme of other as well.

So we need to find a general approach which would not need to change the schemes of other. There is no straightforward solution available, as we do not have an easy way to copy a database, e.g. Database.copy() does nto exist and copy.deepcopy() does not work.