Yuriy Kaminskiy wrote:
>Check
>PRAGMA secure_delete;
>(and disable if it was enabled by default; it would be rendered
ineffective by your trick anyway).
It is not enabled.
>Probably there are way to make it work (altering PRAGMA schema_version; or
>something), but I think it is way to hackerish and unsafe to use such
tricks in
>anything resembling production code.
>Basically, you break consistency of your database image (and then
kind-of-"fix"
>it with vacuum;).
Yes, and that's why I asked here.
"The Truncate Optimization" talks about something, but it's still quite
slow.
To understand what I'm saying, please just try it; fill a dummy db until
it's a few GB in size then try to "clear" it *quickly*.
-----------------
Michael wrote:
>Why don't you just attach another database and switch your user
connections to that one?
>Then you can just delete the old file and not worry about vaccum at all.
Unfortunately this is not an option at this time; readers are different
independent processes, which are just prepared to handle a truncate...
>Sounds though like sqlite3 could use a "truncate" command like Oracle
has which is the speedy way to zero out a table there.
This is what I asked for; but even with "Truncate Optimization" it still
takes quite some time. It might be hard to avoid, because it probably
needs to go through the btree to free pages.
But I really believe that a "clear" for the db should be relatively easy
to do it *fast*; even if it's done without journaling, because it makes
no real sense to journal a full delete (it means a full backup).
This is what I done via "delete from sqlite_master" / "vacuum", but I
needed to be safe, therefore inside a transaction...
Gabriel
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
