Rafal Somla, 22.10.2009 13:40:
> Ingo Strüwing wrote:
>> Rafal Somla, 14.10.2009 14:34:
> 1. I think that doing backup location management using (non-standard)
> SQL statements is a rather bad idea and I think it is unlikely we will
> ever go that way.
An INFORMATION_SCHEMA.BACKUP_LOCATIONS table won't break SQL
compatibility too much, IMHO.
> 2. I think that from business perspective, it is good strategy to
> implement only core tools in the free code and then have opportunity to
> sell applications which make managing the system easier.
> My vision is that some day "MySQL Administrator" will be extended with
> backup functionality. It will have its infrastructure for managing
> backups including managing backup locations, backup scheduling etc. It
> will have nice GUI for performing all these tasks. Under the hood it
> will connect to server and use our BACKUP/RESTORE statements to perform
> the operations. The tool will keep track of backup locations and provide
> correct location strings to these statements.
But then it will have to do so, bypassing the server. This means that
the storage modules need a second API for management purposes.
Ingo Strüwing, Database Group
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Geschäftsführer: Thomas Schröder, Wolfgang Engels, Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin Häring HRB München 161028