> I'll follow this sequence with the purpose in mind of finding a way to
> work around the current design limitation of having O(p) plugin tables
> .
Actually, there will be O(p)+1 tables. One for the default product.
I share your concern regarding limitation of such design but plugin
SQL operatios are black box for us. Adding a column into plugin table
is not always a solution. There are cases when things break. For
example, integrity can fail (e.g. unique indexes) or if plugin sends
insert like:
{{{ INSERT INTO MyTabel SELECT * FROM AnotherTable }}} - additional
column breaks such operation and I believe there much more case we are
not aware.>From my perspective, we have three groups of translated tables: 1. don't touch 2. translate with column - for known tables, like we did for ticket, milestone, wiki etc. tables 3. translate with table name prefixing - for unknown tables. The safest but the most resource consuming solution. Theses group should be configurable. Based on plugin specifics, plugin tables can be moved from group 3 to group 2 or even group 1. Andrej
