The installer script does already table name replacements. So, I don't
see a reason why is would be complicate to extend it for configurable
database names.
It does this only for known tables (these in initial schema file). So,
for your case of dynamic table names it will not work. Besides that,
one
option (prefix) is better than a mass of separate options (for each
table).
Is this really a valid argument? The plugin developer has to take care
about schema updates of plugin tables. In my example: If I duplicate
cache tables for a plugin I have to take care that these tables are
updated when you change the schema in core.
The real problem with the prefix is that it refers to ALL tables in the
database. The advantage of the previous/removed method is that it can be
used for single tables.
_______________________________________________
Roundcube Development discussion mailing list
dev@lists.roundcube.net
http://lists.roundcube.net/mailman/listinfo/dev
