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.
