[OSM-dev] Is there a way to use simple schema without hstore

Andreas Kalsch andreaskalsch at gmx.de
Sun Nov 21 17:04:43 GMT 2010

Postgres is a dirty hack when you write serverside JS.
But this not a problem, because it is stable and has many features.

Am 21.11.10 16:43, schrieb Sarah Hoffmann:
> On Sat, Nov 20, 2010 at 11:52:58AM +1100, Brett Henderson wrote:
>> On Fri, Nov 19, 2010 at 10:50 PM, Sarah Hoffmann<lonvia at denofr.de>  wrote:
>>> On Fri, Nov 19, 2010 at 09:37:33AM +0100, Andreas Kalsch wrote:
>>>>> If you're applying diffs to the database you can enhance the
>>>>> osmosisUpdate() function (initially empty, but can be customised) to
>>>>> keep your separate tags tables up to date during each diff
>>>>> application.  You will need to run the
>>>>> "pgsql_simple_schema_0.6_action.sql" script against the database so
>>>>> that all actions during a diff are logged and can be used by your
>>>>> osmosisUpdate function to know which records need to be re-processed.
>>>> Is it possible to truncate the actions table for myself so that a
>>>> separate script can access the changes?
>>> Simply copy away the information from the action table somewhere
>>> persistent in the osmosisUpdate function. Works fine.
>>> However, +1 from me for an action table that can be truncated manually.
>> Is there likely to be a noticeable performance improvement in doing this?
> I doubt that. Compared to the entire update task, the overhead of copying
> is negligible. It is more a design question. I prefer to keep osmosis and
> the scripts for derived tables strictly apart. Doing part of the update
> process for derived tables in the osmosisUpdate function intermangles the
> two and is very difficult to debug. What was the idea behind osmosisUpdate?
> To allow the code to be executed within the same transaction as the changeset
> application?
>> My preference if the overhead is small would be to add a contrib script to
>> Osmosis that installs a non-truncating table that is updated by
>> osmosisUpdate, and a customised osmosisUpdate function.  It keeps the pgsql
>> tasks simpler if I can do that.
> I would have expected that an implementation without update function and a
> persistent action table is simpler. Or do you mean, providing both variants
> is too complex? In that case, don't worry about it. The current osmosisUpdate
> does what I need and writing an apropriate function is simple. I'll just no
> longer think of it as a quick and dirty hack but as the proper way to do
> it. ;)
> Sarah
> _______________________________________________
> dev mailing list
> dev at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/dev

More information about the dev mailing list