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.
