[OSM-dev] API Logic

SteveC steve at asklater.com
Fri Jan 25 16:20:43 GMT 2008


On 25 Jan 2008, at 16:16, Tom Hughes wrote:

> In message <5668239F-D932-4A5A-B18D-AA39DBC3A2AE at asklater.com>
>        SteveC <steve at asklater.com> wrote:
>
>> On 25 Jan 2008, at 15:37, Tom Hughes wrote:
>>
>>> In message <85B67797-8971-4352-98A9-13DFD451AE3E at asklater.com>
>>>       SteveC <steve at asklater.com> wrote:
>>>
>>>> * needs to know how to update the tile attribute when updating many
>>>> nodes (no clue how that's done). Actually it doesn't need to as it
>>>> can
>>>> just copy the current tile as the node is being deleted not moved.
>>>> But
>>>> more generally it's probably a good idea if I figure out what's
>>>> needed.
>>>
>>> This is done automatically by a before_save callback in the  
>>> GeoRecord
>>> model that the Node models are derived from.
>>
>> right, but it's on a per-instance basis? If I want to update 10,000
>> nodes what does it do?
>
> Well it runs as each node is saved, but the cost relative to the cost
> of doing 10000 SQL update statements is probably minimal.
>
> If you really want to do batch updates you can use the MySQL function
> instead (although then you'll have to dodge the rails object model
> anyway which I thought you were trying to avoid).

Richards stuff does a lot of things through mass updates... If I  
delete all the nodes in a way then I dont want to find them all and  
delete them all. You can instead do

Node.delete([1,2,3,4,5])

in rails and so things like

Node.update([1,2,3,4,5], :visible => false, :used_id = 42)

which is one query instead of 100,000 right?

Frankly I couldn't care less, but Richard will scream if the function  
is slow.

But again for the updates and deletions I can just copy the tile  
attribute from the existing nodes and use that when creating the  
OldNode's. It's only when mass creating new ones that it matters, and  
I haven't got to that yet.

have fun,

SteveC | steve at asklater.com | http://www.asklater.com/steve/




More information about the dev mailing list