mysqldump table filtering thoughts

[Tim Soderstrom]

So I have been wondering how useful allowing table inclusions or exclusions without the "db.table" syntax actually is. I know we had a recent bug around this and I cannot think of a good reason to allow something like "*timezone" instead of "mysql.*timezone". For doing crazy things, I would imagine it would be better to do something like "m*.*time" and crazy stuff like that.

So, in a nutshell, what are the thoughts on forcing the db.table notation? Is that feasible in Holland or useful?

Tim "Sweetums" Soderstrom
MySQL DBA Services

Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is prohibited.
If you receive this transmission in error, please notify us immediately by e-mail
at ab...@rackspace.com, and delete the original message.
Your cooperation is appreciated.

[Andrew Garner]

I think the bug was simply that 'bare' table names weren't working due
to a regression in 0.9.9 -> 1.0. I'm not sure that it's such a big
deal to support these - the initially reason to do this was mimicking
how Maatkit's tools work, and that's kind of convenient in some cases.
In Maatkit land, I would use this where I know i"m limiting scope to
a single database and don't want to redundantly add a 'db.' prefix to
each table name.

The current holland config format doesn't support multi-line lists
(since we're using ConfigObj), so database.table can make a single
line much longer (and, subjectively, less readable). I'm really
wanting to solve that for 1.1.

However, I'm pretty neutral on the issue. If the consensus is that
bare table names are a footgun, we can add logic to report this as an
error. Or at least we can log a loud warning to note that we're
rewriting 'table' to '*.table'.

~Andy

> --
> WIKI: http://wiki.hollandbackup.org
> CODE: http://github.com/holland-backup
> UNSUBSCRIBE: holland-deve...@googlegroups.com
>

[Tim Soderstrom]

Good point on the single-line issue. Was not considering that. The only real issue I have with the lack of the db.table syntax is that it becomes harder to understand what's going on (say if there are multiple databases in a backup-set). So this is mostly to avoid confusion over lack of function.

At this point, we can probably push this discussion off to 1.1 thinking about it. Probably should avoid making any super big changes to 1.0 anyway and since people may be using the table-filtering in its current incarnation, that may break compatibility with previous 1.0 releases, which might not be so great.

Hmm...don't really want to log a bug on this though. Perhaps we should add a Holland 1.1 wiki page if everyone is good with that?

[Andrew Garner]

I think a wiki page is a good idea. If we were on launchpad, we could
create a blueprint.

~Andy

[Tim Soderstrom]

Done. It's mostly a stub page, but it's there:

http://hollandbackup.org/Holland1-1

[Andrew Garner]

I added some of the stuff I had in mind there. Some of it is
pie-in-the-sky (although most of those items have good
proof-of-concepts). Anyone is free to add to it or add wishlist
items.

~Andy

On Tue, Jul 20, 2010 at 5:56 PM, Tim Soderstrom

[Tim Soderstrom]

Nice work there. Good stuff and I noticed you cleaned up my sort of lame grammar :) I think you covered most of the stuff I was thinking of. I didn't see the web interface stuff there - that something we might focus on for 2.0?

[Andrew Garner]

On Wed, Jul 21, 2010 at 8:50 AM, Tim Soderstrom
<t...@moocowproductions.org> wrote:
> Nice work there. Good stuff and I noticed you cleaned up my sort of lame grammar :) I think you covered most of the stuff I was thinking of. I didn't see the web interface stuff there - that something we might focus on for 2.0?

That's a good point. This is doable for 1.1, time permitting. I
think this will be a lot easier once after some cleanup in
holland.core and dropping support for python-2.3 (or requiring
python-2.6+). I added some notes on what I had in mind for the web
interface. This is pretty low priority though.

~Andy