Hello Devs,
could you please let me know why configurable table names have been removed from Roundcube 1.0? Currently it is only possible to prefix database tables. The old method was much more flexible. Is there a chance to get it back?
Regards, Rosali
Roundcube 0.9.x, rcube_db.php:
{{{
public function table_name($table)
{
$rcube = rcube::get_instance();
// return table name if configured
$config_key = 'db_table_'.$table;
if ($name = $rcube->config->get($config_key)) {
return $name;
}
return $table;
}
}}}
Roundcube 1.0, rcube_db.php:
{{{ public function table_name($table) { static $rcube;
if (!$rcube) {
$rcube = rcube::get_instance();
}
// add prefix to the table name if configured
if (($prefix = $rcube->config->get('db_prefix')) &&
strpos($table, $prefix) !== 0) { return $prefix . $table; }
return $table;
}
}}}
On 04/24/2014 10:52 AM, Rosali wrote:
could you please let me know why configurable table names have been removed from Roundcube 1.0? Currently it is only possible to prefix database tables. The old method was much more flexible. Is there a chance to get it back?
We want keep this as simple as possible. Custom table names are harder to handle in schema upgrades.
On 04/24/2014 10:52 AM, Rosali wrote:
could you please let me know why configurable table names have been removed from Roundcube 1.0? Currently it is only possible to prefix database tables. The old method was much more flexible. Is there a chance to get it back?
We want keep this as simple as possible. Custom table names are harder to handle in schema upgrades.
OK. Then ignore it for schema updates and bring it back just due backwards compatibility. Also the old method is quite handy for plugin developers. F.e.: My imap_identities plugin could easily implement cacheing if there was the old method still available (dynamic database table configuration for the different single sign-on IMAP accounts).
Hey,
Am 24.04.2014 11:03, schrieb A.L.E.C:
On 04/24/2014 10:52 AM, Rosali wrote:
could you please let me know why configurable table names have been removed from Roundcube 1.0? Currently it is only possible to prefix database tables. The old method was much more flexible. Is there a chance to get it back?
We want keep this as simple as possible. Custom table names are harder to handle in schema upgrades.
Problem is, that a lot of the webhosting providers around still give you only one MySQL database for cheap webhosting solutions. For situations like that, table prefixes are a requirement to prevent namespace conflicts with other web applications.
Kind regards, jonas
Am 24.04.2014 11:28, schrieb Jonas:
Am 24.04.2014 11:03, schrieb A.L.E.C:
On 04/24/2014 10:52 AM, Rosali wrote:
could you please let me know why configurable table names have been removed from Roundcube 1.0? Currently it is only possible to prefix database tables. The old method was much more flexible. Is there a chance to get it back?
We want keep this as simple as possible. Custom table names are harder to handle in schema upgrades.
Problem is, that a lot of the webhosting providers around still give you only one MySQL database for cheap webhosting solutions. For situations like that, table prefixes are a requirement to prevent namespace conflicts with other web applications.
Sorry, I mixed up table name prefix and dynamic table names. Please ignore my mail :-/
Kind regards, jonas
On 04/24/2014 10:52 AM, Rosali wrote:
could you please let me know why configurable table names have been removed from Roundcube 1.0? Currently it is only possible to prefix database tables. The old method was much more flexible. Is there a chance to get it back?
We want keep this as simple as possible. Custom table names are harder to handle in schema upgrades.
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.
{{{
$this->config['db_prefix'] . $table;
}}}
... becomes ...
{{{
if (!empty($this->config['db_table_' . $table])) { $table = $this->config['db_table_' . $table]; } $this->config['db_prefix'] . $table;
}}}
... and ...
{{{
private function fix_table_names($sql, $DB) { if (empty($this->config['db_prefix'])) { return $sql; }
}}}
... becomes ...
{{{
private function fix_table_names($sql, $DB) { if (empty($this->config['db_prefix']) && empty($this->config['db_table_' . $table])) { return $sql; }
}}}
Any concerns?
On 04/24/2014 12:21 PM, Rosali wrote:
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).
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.
-
A.L.E.C -
Jonas -
Rosali