Re: MySQL::Backup?
Assuming it is based on DBI at its core, your module would fit better in the DBI extension area. I think DBIx::Backup::MySQL would be good, as it would leave room for expansions to databases other than ::MySQL. Chris On Oct 25, 2004, at 3:00 PM, Sean Quinlan wrote: Good afternoon, I've been working on a tool for automating log rotations and database dumps for MySQL. This started during system administration discussions in a development group I was in at MGH quite a while ago, and a few people were involved in writing the first versions. I've just recently gotten back to working on it again. I now have a working version that is being tested at a couple of sites. I would be happy to send it to anyone (or the list) on request. It has three components, a module, a conf file and a tiny script for initiating backups, generally to be run by daily cron job. The documentation is scattered about a bit still, but should be functionally correct. I would welcome any feedback on the module name. I've got it as MySQL::Backup at the moment, and don't see anything currently on CPAN in that name space. Does anyone have any other recommendations or concerns before I upload it to PAUSE? Thanks! -- Sean Quinlan [EMAIL PROTECTED] -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, 313 W Beltline Hwy Suite 41, Madison WI 53713 PGP.sig Description: This is a digitally signed message part
Re: MySQL::Backup?
Christopher Hicks writes: On Tue, 26 Oct 2004, Smylers wrote: ... DBIx:: should be for things that are generally usable with DBI, where the I is independent ... I agree with Chris much more than Smylers here, but if we go along with Smylers perspective for a minute then we need /some/ hierarchy for database-related things that aren't avertising they're using DBI for some reason. Why? There are several top-level namespaces on Cpan that are simply the names of some external software that the modules in that namespace work with. In particular, there are already many in the MySQL:: namespace: http://search.cpan.org/search?m=moduleq=MySQLs=1n=20 It may not be a perfect namespace, but it certainly isn't terrible, it's unambiguous, and surely it's better to keep on using it for similar 'MySQL'-related modules than to put new ones elsewhere (or persuade all the existing ones to move)? The more I think about it DBIx would seem to be the winning place for this sort of thing. When I read Mark's message I realized his point is what I'd been wanting to say in the first place; so the more _I_ think about it, the more DBIx:: seems like a completely inappropriate place for this module! Smylers
Re: MySQL::Backup?
On Tue, 26 Oct 2004, Smylers wrote: Christopher Hicks writes: On Tue, 26 Oct 2004, Smylers wrote: ... DBIx:: should be for things that are generally usable with DBI, where the I is independent ... I agree with Chris much more than Smylers here, but if we go along with Smylers perspective for a minute then we need /some/ hierarchy for database-related things that aren't avertising they're using DBI for some reason. Why? So that database-related things are kept together. There are several top-level namespaces on Cpan that are simply the names of some external software that the modules in that namespace work with. We have that for Oracle and Sybase, but does that make it easier on people trying to find related things? If something is database related and based on DBI I'd like to see it in DBIx. If its something that is database related and its based on some other interface it should be in Database:: or SQL:: In particular, there are already many in the MySQL:: namespace: http://search.cpan.org/search?m=moduleq=MySQLs=1n=20 Precedent means a lot more in a court of law than it should elsewhere. It may not be a perfect namespace, but it certainly isn't terrible, it's unambiguous, and surely it's better to keep on using it for similar 'MySQL'-related modules than to put new ones elsewhere (or persuade all the existing ones to move)? I don't think we can persuade all of the existing ones to move, but if we had a general agreement that database related modules should be in a handful of namespaces it would seem to be advantageous. I'd love to see see Alzabo. MySQL::Backup, and the other DBI-based modules with strange names paces all go in DBIx while the other things (oraperl, postgres, etc.) go into Database::. We have Spreadsheet:: to take care of spreadsheets. The more I think about it DBIx would seem to be the winning place for this sort of thing. When I read Mark's message I realized his point is what I'd been wanting to say in the first place; so the more _I_ think about it, the more DBIx:: seems like a completely inappropriate place for this module! How is doing a database backup any less of a DBI extension than DBIx::Copy or DBIx::HTMLView? -- /chris There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare
Re: MySQL::Backup?
On Tue, Oct 26, 2004 at 04:34:32PM -0400, Christopher Hicks wrote: When I read Mark's message I realized his point is what I'd been wanting to say in the first place; so the more _I_ think about it, the more DBIx:: seems like a completely inappropriate place for this module! How is doing a database backup any less of a DBI extension than DBIx::Copy or DBIx::HTMLView? If I want to back up my MySQL dataqbase, why do I care what the underlying library is? How does making it DBIx:: benefit the end user? Seems like DBIx:: might be more reasonable if there were a whole class of related backup libraries. But if there is just the singular one for MySQL and not much chance of there being some portable equivalent for other libs, perhaps it's better to not use the more generic namespace. That way if someone later on writes a generic backup tool as a DBI extension the namespace will be available and not polluted by unrelated tools. *shrug* Austin
Re: MySQL::Backup?
On Tue, 26 Oct 2004, _brian_d_foy wrote: In article [EMAIL PROTECTED], Smylers [EMAIL PROTECTED] wrote: I think the opposite -- that DBIx:: should be for things that are generally usable with DBI, where the I is independent. Things such as backing up tend not to be database-independent. if we work it right, DBIx::Backup could be independent, while DBIx::Backup::MySQL implements the MySQL bits. :) Exactly. If DBIx::Backup::MySQL has a clean interface it might even inspire a generic DBIx::Backup and become the MySQL implementation of DBIx::Backup and spark a revolution in database administration. :) -- /chris There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare
