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 fixtur
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
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
nat
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 fu
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 wi
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 incred
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
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 backu
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 e
9 matches
Mail list logo
