I solved a similar case by writing a function to a) use native postgres dump and archive the database and b) present the file to the user for download in the administrative back-end. This function is triggered by cron in my case, but it could also be executed on demand. For this I would use the scheduler and throw in some additional checks so the user doesn't trigger the backup too often.
Hope this helps a bit. Regards, Ales On Thursday, March 21, 2013 2:42:51 PM UTC+1, dederocks wrote: > > Indeed, or quite close: > https://code.google.com/p/web2py/issues/detail?id=1387. > And to be accurate, I think the issue has more to do with restore than > backup. > > To build on your comment, there are indeed two ways to deal with backup / > restore: > 1- managed by the database manager using native backup / restore; > 2- managed by the user, to send the db to another colleague, or restore an > older version through the application. > That's what I'm dealing with right now, and it fails on me. > > Le jeudi 21 mars 2013 13:49:24 UTC+1, LightDot a écrit : >> >> Quite right, restoring from, let's say, native mysql dump to postgresql >> would most certainly not work. That's exactly why web2py uses csv as the >> export format. >> >> I don't think exporting / importing to csv is really recommended over >> using the native export / import functionality of your database engine or a >> specialized backup software (depending on your needs). But it works and it >> quickly covers the most broad spectrum possible. For anything more specific >> or complex, it's up to the developer to use something else. I don't think >> web2py should try to reinvent the wheel here. >> >> If export to csv failed in your case, what exactly was the problem? The >> referenced thread is from 2011 and seems to be case specific... Are you >> saying you have the same exact error? >> >> Regards, >> Ales >> >> >> On Thursday, March 21, 2013 11:12:57 AM UTC+1, dederocks wrote: >>> >>> I'm concerned with the lack of reliability and speed of the recommended >>> backup / restore functions: db.export_to_csv_file and >>> db.import_from_csv_file. >>> They failed in my case, and apparently I'm not alone ( >>> https://groups.google.com/forum/?fromgroups=#!newtopic/web2py/web2py/reOzXobYNgE >>> ). >>> Would it be wise to replace the backup function with something like: >>> import os >>> if 'sqlite' in db._uri: >>> os.system(' '.join(('sqlite3',db.path,'.dump >',targetfile))) >>> elif 'postgres' in db._uri: >>> os.system(' '.join(('pg_dump -f',targetfile, dbname))) >>> elif 'mysql' in db._uri: >>> os.system(' '.join(('mysqldump -r',targetfile, dbname))) >>> >>> and similarly the restore function would be: >>> import os >>> if 'sqlite' in db._uri: >>> os.system(' '.join(('sqlite3',db.path,'<',sourcefile))) >>> elif 'postgres' in db._uri: >>> os.system(' '.join(('pg_restore -d',dbname, sourcefile))) >>> elif 'mysql' in db._uri: >>> os.system(' '.join(('mysqlimport',dbname, sourcefile))) >>> >>> Unfortunately I'm not knowlegable enough (yet) about all the various >>> databases supported nor about platform-dependent intricacies, but would >>> this not be a more reliable approach? >>> The only major downside is that restoring a db from x (say sqlite) into >>> y (say postgresql) might not be possible, or require some significant edit >>> of the dump file. And to make the restore smoother, you'd have to figure >>> out the source format -- is this possible? >>> >> -- --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
