Sure. As long as what can and cannot be expected from the functions is clear, I'm happy with your way!
Le jeudi 21 mars 2013 16:44:17 UTC+1, Niphlod a écrit : > > my point exactly .... it's a matter on how it's perceived as a > one-solution-for-all-exporting-problem vs a rapid way to load fixtures/etc > in your environment. > > On Thursday, March 21, 2013 4:41:48 PM UTC+1, Anthony wrote: >> >> 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.
