On 17 Nov 2012, at 04:42, Brett Henderson <[email protected]> wrote: > Hi Shaun, > > On 16 November 2012 22:17, Shaun McDonald <[email protected]> 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.
It's due to me loading the DB, creating another user to allow editing, clearing the DB to import another set of data, then trying to use it. In this case a custom db clearing task is best. Thanks for the explanation. Shaun
_______________________________________________ osmosis-dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/osmosis-dev
