[collectd] [PATCH] mysql plugin: add support for multiple databases

[Sebastian Harl]

Hi again,

On Tue, Mar 17, 2009 at 10:05:32AM +0100, Florian Forster wrote:
> This whole ``database as in the daemon you connect to'' vs. ``database
> as in the thing that holds tables together'' is confusing as hell. Maybe
> we should rename the blocks to something more distinct, such as `DBMS'
> or `Connection'?

Hrm ... then we should change it in the dbi, postgresql, ... plugins as
well which would introduce yet another load of deprecated stuff. Anyway,
I agree that something like "Connection" would be more generic - I came
up with "Database" when implementing the postgresql plugin since there
is no real difference between the two terms in that case (you actually
connect to a database there) - I see that mysql is different though.

So, frankly, I'm not really sure about the best way to solve that. In
any case, I strongly discourage inconsistencies between the different
database plugins.

> What about adding a ``Database'' option to the (possibly renamed)
> <Database> blocks? This way plugin instance and database name could be
> separate. This would make sense imho, because I think this `Database'
> option is often unset.

Agreed, that would make sense - at least in the case of the mysql
plugin. In case of the postgresql plugin this option would have to be
mandatory though, which I don't consider to be a problem though.

> One thing that has bugged me for a long time are the `mysql_qcache' and
> `mysql_threads' types. What do you think about taking this opportunity
> to straighten this up? I. e. use these types only when in legacy mode
> and use new, better, more polished types when in non-legacy mode?

Imho, it's not a good idea to do that before 5.0. Changing types would
require users to migrate their existing data when switching to the new
syntax. Of course, that step would be optional but still this would imho
be a "somewhat backward-incompatible" step. At the very least, it's not
nice to have to choose between getting warnings about deprecated stuff
or having to migrate data.

So, I guess, I'd vote for not doing any of those changes right now but
rather schedule them for 5.0. Maybe we should think about releasing 5.0
in a not too far future - possibly something like the end of the year or
the beginning of next year ...

Just my 2c ...

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety.         -- Benjamin Franklin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.verplant.org/pipermail/collectd/attachments/20090317/2bb21ef7/attachment.pgp