Hi michael, 2007/7/24, michael <[EMAIL PROTECTED]>: > Hello Christophe, > > If I am reading you intent (and forgive me if I am wrong), you would > like to have one backup/restore routine for the same schema but on a > variety of databases.
Yes > And, you want the user to be responsible for > doing both actions. More precisely, I want to be able to provide a tool the user which allow him to do it with minimal knowledge. > > Your references to "universal dump format" and "common backup format" > point sqarely at a flat file; which can sometimes be > [tab|space|comma|pipe|etc] delimited. Since you said that your > databases will be small, text is truly universal. It does not require > python or any scripting language and can easily be viewable in any text > editor. As a side note, I have found pipe delimited to be the least > troublesome when moving between databases that have user-input data. Agree on the flat file. A Zipped Archive of flat files would do the trick I guess. What I found interesting with pytable is the high accessibility of the data, even in a compressed file. This would make easier the implementation of a partial restore. But this is just an idea I'm throwing, maybe I'm totally wrong on what pytables would bring. > The first thing that comes to mind is that there should probably > already be an automated backup scheduled. Users will forget and when a > restore is needed, they will want fresh data. > > Each database has their own export-to-text command and each has their > own import-from-text command; and related syntax. This can be triggered > with cron for all unixes; On Windows, MSSQL has its own scheduler. (Of > course, one could also have a button do the same thing, in *addition* to > routine backups.) I agree, but that's almost orthogonal with what I have in mind. What you suggest is what should be done by a descent admin or consultant who is installing the software. I have two real-life cases which are not covered by this approach : 1) My 'packaging team' prepares demonstrations databases as well as ready-to-start ones. I want those databases to be accessible on our website, easily choosable (idealy without having to know which database server is used), and easily usable from within my app. 2) A user call the support team, and the problem seems to come from bizarre datas in the database. I want the user (if he has the rights) to be able to save his datas, attach them to an email and send it to the support (or post it on a support form on the website). > Are you asking for features in SA to handle scheduled backups and > user initiated restores? No. What I'd like to do is to provide facilities for dumping and restoring a complete db. And I'd like this to work if to db with different engines have (almost) the same schema. This is a bit the same with migrate which is providing engine-agnostic api for shema modifications. One could easily, for e.g. build a sadump tool on top of this tool, or a database manager tool for a particular application (this is what I intend to do). All this is 'just a thought' for now, but motivated by an actual future need. Christophe --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
