Removing the functionality altogether seems extreme. However, perhaps we should change the documentation to remove the backup/restore terminology (i.e., we can describe it as a way to "export" and "import" an entire db, but not recommend it as a primary backup strategy and instead recommend native db functionality for that purpose).
Anthony On Thursday, March 21, 2013 10:57:05 AM UTC-4, dederocks wrote: > > Yes - unless someone finds a good use for these two functions. > It looks to me that if a record has been removed in a db (e.g. id is not > continuous: 1, 2, 4, 5 for example), the restore won't work if the table is > linked to another table. This is I think a sufficiently likely case to > remove the functions - or am I wrong? > > Le jeudi 21 mars 2013 15:42:51 UTC+1, Niphlod a écrit : >> >> so you'd prefer to have it removed alltogether ? >> >> On Thursday, March 21, 2013 3:37:44 PM UTC+1, dederocks wrote: >>> >>> Thanks Ales, >>> Basically, you're confirming the native backup / restore choice. I'm >>> concerned though that web2py's csv solution is not reliable, and should >>> therefore be used with high caution -- not to say a word about how slow it >>> is. It feels sad for me that web2py which other than that an incredible >>> tool keeps this unpractical feature. >>> >>> Regards, >>> Andre >>> >>> Le jeudi 21 mars 2013 15:09:23 UTC+1, LightDot a écrit : >>>> >>>> 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.
