[osmosis-dev] --truncate-apidb also truncates users
Brett Henderson
brett at bretth.com
Sat Nov 17 04:42:06 GMT 2012
Hi Shaun,
On 16 November 2012 22:17, Shaun McDonald <shaun at shaunmcdonald.me.uk> wrote:
> Based on the docs at
>
> http://wiki.openstreetmap.org/wiki/Osmosis/Detailed_Usage_0.42#--truncate-apidb_.28--td.29
> for --truncate-apidb, I wasn't expecting that it would truncate the user
> table and all the other related tables, that are no API docs.
>
> However based on the code at
>
> https://github.com/openstreetmap/osmosis/blob/master/apidb/src/main/java/org/openstreetmap/osmosis/apidb/v0_6/ApidbTruncator.java#L23
> it does in fact truncate the user table too. Is this intentional
> behaviour? Could it be change such that only Osmosis generated users are
> removed or users are left behind?
>
The documentation could probably be more explicit, but it will truncate any
table that Osmosis populates during import. The idea is that if you have a
populated database, you need to run truncate before you can perform a fresh
import.
The import process is very dumb and assumes an empty database. Trying to
check for existing data would be more complicated and slower.
The current import process is just using insert statements, but longer term
I'd like to see it move over to using the PostgreSQL COPY command. COPY is
*much* faster and is already used by the pgsnapshot schema. If COPY is
used then the database tables must be empty before import anyway. This is
another reason that I'm hesitant to add any existing user checks to the
current implementation.
Why is this causing you problems? If you have special needs, performing a
manual truncate is fairly trivial.
Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/osmosis-dev/attachments/20121117/d04b2fd6/attachment.html>
More information about the osmosis-dev
mailing list