On Wed, Feb 11, 2009 at 2:32 AM, Brett Henderson br...@bretth.com wrote:
Iván Sánchez Ortega wrote:
El Miércoles, 11 de Febrero de 2009, Shaun McDonald escribió:
Having a slightly less efficient import that ensures consistency is a
great thing, as it means that the database doesn't grow
On 11 Feb 2009, at 01:36, Iván Sánchez Ortega wrote:
El Miércoles, 11 de Febrero de 2009, Shaun McDonald escribió:
Having a slightly less efficient import that ensures consistency is a
great thing, as it means that the database doesn't grow too quickly.
I fail to see why slower growth is a
On 11 Feb 2009, at 08:52, 80n wrote:
On Wed, Feb 11, 2009 at 2:32 AM, Brett Henderson br...@bretth.com
wrote:
Iván Sánchez Ortega wrote:
El Miércoles, 11 de Febrero de 2009, Shaun McDonald escribió:
Having a slightly less efficient import that ensures consistency
is a
great thing, as
On Wed, Feb 11, 2009 at 9:09 AM, Shaun McDonald
sh...@shaunmcdonald.me.ukwrote:
On 11 Feb 2009, at 08:52, 80n wrote:
On Wed, Feb 11, 2009 at 2:32 AM, Brett Henderson br...@bretth.com wrote:
Iván Sánchez Ortega wrote:
El Miércoles, 11 de Febrero de 2009, Shaun McDonald escribió:
Having
80n wrote:
On Wed, Feb 11, 2009 at 9:09 AM, Shaun McDonald
sh...@shaunmcdonald.me.uk mailto:sh...@shaunmcdonald.me.uk wrote:
I fail to see why slower growth is a good thing?
Slower (perhaps steady is a better word) growth has its
advantages for
On Wed, Feb 11, 2009 at 11:02 AM, Raphaël Jacquot sxp...@sxpert.org wrote:
Iván Sánchez Ortega wrote:
WTF does this happen on every object (read: node) I upload? The API already
knows who I am the second I started to upload the diff!
troll
that's rails for you...
the thing attempts to do
Frederik Ramm wrote:
Hi,
Iván Sánchez Ortega wrote:
I just finished coding a bulk importer which interfaces directly to the
MySQL
DB instead of interfacing to the API.
Well then I say let's just politely ask TomH to open up the MySQL TCP
port for public access and create user
On Wed, 11 Feb 2009 12:11:38 +0100, Raphaël Jacquot sxp...@sxpert.org
wrote:
Frederik Ramm wrote:
Hi,
Iván Sánchez Ortega wrote:
I just finished coding a bulk importer which interfaces directly to the
MySQL
DB instead of interfacing to the API.
Well then I say let's just politely ask
El Miércoles, 11 de Febrero de 2009, Raphaël Jacquot escribió:
Jokes aside, does your bulk importer also implement populating the
history tables, making sure that every node referenced by a way (and
every node/way/relation referenced by a relation) actually exists, and
all these totally
Hi,
Iván Sánchez Ortega wrote:
all this should be mostly handled by the db server with appropriate
foreign key constraints, not by the application code
+1
Rails guys: we're using InnoDB tables for a reason, you know.
I'm not a foreign keys guru myself but I think it may be difficult to
On Wed, Feb 11, 2009 at 1:03 PM, Iván Sánchez Ortega
i...@sanchezortega.es wrote:
El Miércoles, 11 de Febrero de 2009, Raphaël Jacquot escribió:
Jokes aside, does your bulk importer also implement populating the
history tables, making sure that every node referenced by a way (and
every
Frederik Ramm wrote:
Iván Sánchez Ortega wrote:
all this should be mostly handled by the db server with appropriate
foreign key constraints, not by the application code
+1
Rails guys: we're using InnoDB tables for a reason, you know.
I'm not a foreign keys guru myself but I think it may
El Miércoles, 11 de Febrero de 2009, Stefan de Konink escribió:
I'm not a foreign keys guru myself but I think it may be difficult to
have one with the relation_members as designed currently.
I have solved that by splitting the members in 3 distinct tables; but
placed an explicit index so I
On Wed, 11 Feb 2009 14:48:58 +0100, Iván Sánchez Ortega
i...@sanchezortega.es wrote:
El Miércoles, 11 de Febrero de 2009, Stefan de Konink escribió:
I'm not a foreign keys guru myself but I think it may be difficult to
have one with the relation_members as designed currently.
I have solved
Iván Sánchez Ortega wrote:
El Miércoles, 11 de Febrero de 2009, Raphaël Jacquot escribió:
Jokes aside, does your bulk importer also implement populating the
history tables, making sure that every node referenced by a way (and
every node/way/relation referenced by a relation) actually exists,
Shaun McDonald wrote:
I've been busy trying to fix the server Potlatch code so that
it in many cases the corruption will no longer occur, as it is
now doing it in a similar way to the XML api, or also
incorporating it into a transaction.
amf_controller hasn't been the source of any
Iván Sánchez Ortega wrote:
El Miércoles, 11 de Febrero de 2009, Stefan de Konink escribió:
I'm not a foreign keys guru myself but I think it may be difficult to
have one with the relation_members as designed currently.
I have solved that by splitting the members in 3 distinct tables; but
On Wed, Feb 11, 2009 at 1:55 PM, Iván Sánchez Ortega
i...@sanchezortega.es wrote:
For changeset timeouts: triggers, triggers, triggers. Or just initialize the
closing time of a changeset to a date in the future.
the closing time trick is how the rails code works. would you also add
triggers for
On Tue, Feb 10, 2009 at 1:01 AM, Frederik Ramm frede...@remote.org wrote:
Hi,
Iván Sánchez Ortega wrote:
[2009-02-10 01:00:34.809017 #1664] User Load (0.000144) SELECT * FROM
`users` WHERE (`users`.`id` = 1)
[2009-02-10 01:00:34.810457 #1664] SQL (0.000144) SELECT `display_name`
Iván Sánchez Ortega wrote:
Sent: 10 February 2009 12:58 PM
To: dev Openstreetmap
Subject: Re: [OSM-dev] Rantings about API 0.6
El Martes, 10 de Febrero de 2009, Matt Amos escribió:
i agree. there is scope for optimisation within rails with varying
degrees of ugliness ;-)
Geez
On Tue, Feb 10, 2009 at 12:58 PM, Iván Sánchez Ortega
i...@sanchezortega.es wrote:
El Martes, 10 de Febrero de 2009, Matt Amos escribió:
i agree. there is scope for optimisation within rails with varying
degrees of ugliness ;-)
Geez, this conversation is making me want to rewrite the API from
Hi,
Iván Sánchez Ortega wrote:
Geez, this conversation is making me want to rewrite the API from scratch in
another language.
What shall I say... if you travel a few hundred kilometres
North-North-East you'll reach a little country with lots of malcontent
but well-funded mappers who are
El Martes, 10 de Febrero de 2009, Andy Robinson (blackadder-lists) escribió:
Geez, this conversation is making me want to rewrite the API from scratch
in another language.
Yeah, would look a whole lot prettier in Spanish :-D
I was talking about LOLCODE, you insensitive clod!
HAI
CAN HAS
On Tue, 10 Feb 2009, Frederik Ramm wrote:
No honestly, I firmly believe that the full API will one day be done in
C/C++.
Except for the GPX/Usermanagement code, I have it all in C :)
Stefan
___
dev mailing list
dev@openstreetmap.org
On Tue, 10 Feb 2009, [utf-8] Iván Sánchez Ortega wrote:
El Martes, 10 de Febrero de 2009, Matt Amos escribió:
i agree. there is scope for optimisation within rails with varying
degrees of ugliness ;-)
Geez, this conversation is making me want to rewrite the API from scratch in
another
El Martes, 10 de Febrero de 2009, Stefan de Konink escribió:
Geez, this conversation is making me want to rewrite the API from scratch
in another language.
For anyone that will do it in assembly; a girly-shirt is also available ;)
Does it come with a girlfriend inside?
--
On Tue, Feb 10, 2009 at 2:11 PM, Iván Sánchez Ortega
i...@sanchezortega.es wrote:
El Martes, 10 de Febrero de 2009, Andy Robinson (blackadder-lists) escribió:
Geez, this conversation is making me want to rewrite the API from scratch
in another language.
Yeah, would look a whole lot prettier
It'll be even faster when served from multiple computers. My friend and
I are using Python, Thrift and Berkeley DB to stretch it across multiple
boxes. It will scale better than any language rewrite.
Cheers.
Scott
Stefan de Konink wrote:
On Tue, 10 Feb 2009, Frederik Ramm wrote:
No
Scott Shawcroft wrote:
It'll be even faster when served from multiple computers. My friend and
I are using Python, Thrift and Berkeley DB to stretch it across multiple
boxes. It will scale better than any language rewrite.
Cherokee, the webserver I wrote it for, comes with something called
On Tue, Feb 10, 2009 at 6:50 PM, Stefan de Konink ste...@konink.de wrote:
Scott Shawcroft wrote:
It'll be even faster when served from multiple computers. My friend and
I are using Python, Thrift and Berkeley DB to stretch it across multiple
boxes. It will scale better than any language
Matt Amos wrote:
the LOLCODE port scales super-linearly (and super-cutely) simply by writing:
ITTEH BITTEH KITTEH COMMITTEH SAIZ
...
KTHXBYE
For the more serious people;
This was the first (most common) implementation:
http://code.nytimes.com/projects/dbslayer
Cherokee extended it to
El Martes, 10 de Febrero de 2009, Matt Amos escribió:
as you say, with any luck the queries for users and changesets will be
cached. so disabling validations would gain us little and admit the
possibility that invalid data gets into the DB somehow... not saving
the changesets on each diff
Hi,
Iván Sánchez Ortega wrote:
I just finished coding a bulk importer which interfaces directly to the MySQL
DB instead of interfacing to the API.
Well then I say let's just politely ask TomH to open up the MySQL TCP
port for public access and create user accounts for us all, and off we
go
On 11 Feb 2009, at 00:18, Frederik Ramm wrote:
Hi,
Iván Sánchez Ortega wrote:
I just finished coding a bulk importer which interfaces directly to
the MySQL
DB instead of interfacing to the API.
Well then I say let's just politely ask TomH to open up the MySQL TCP
port for public
On 11 Feb 2009, at 00:41, Iván Sánchez Ortega wrote:
El Miércoles, 11 de Febrero de 2009, Frederik Ramm escribió:
Hi,
Iván Sánchez Ortega wrote:
I just finished coding a bulk importer which interfaces directly
to the
MySQL DB instead of interfacing to the API.
Well then I say let's
El Miércoles, 11 de Febrero de 2009, Shaun McDonald escribió:
Having a slightly less efficient import that ensures consistency is a
great thing, as it means that the database doesn't grow too quickly.
I fail to see why slower growth is a good thing?
Remember that we are are using transactions
Iván Sánchez Ortega wrote:
Jokes aside, does your bulk importer also implement populating the
history tables, making sure that every node referenced by a way (and
every node/way/relation referenced by a relation) actually exists, and
all these totally useless integrity constraints?
I'm
El Miércoles, 11 de Febrero de 2009, Brett Henderson escribió:
I'm importing brand new data, so populating the history tables is no big
deal.
Perhaps I've misunderstood you but populating the history tables is very
important.
I'm afraid we have a little misunderstanding here :-)
For *new*
Iván Sánchez Ortega wrote:
El Miércoles, 11 de Febrero de 2009, Brett Henderson escribió:
I'm importing brand new data, so populating the history tables is no big
deal.
Perhaps I've misunderstood you but populating the history tables is very
important.
I'm afraid we have a
Hi,
Iván Sánchez Ortega wrote:
(I fail to see why we have to duplicate data here, anyway - I don't know
whether it would be performance-wise to just store the historic information,
and make the API fetch only the last version; or do as now, but not keeping
the last version in the historic
Frederik Ramm wrote:
Iván Sánchez Ortega wrote:
(I fail to see why we have to duplicate data here, anyway - I don't know
whether it would be performance-wise to just store the historic information,
and make the API fetch only the last version; or do as now, but not keeping
the last version
Iván Sánchez Ortega wrote:
El Miércoles, 11 de Febrero de 2009, Shaun McDonald escribió:
Having a slightly less efficient import that ensures consistency is a
great thing, as it means that the database doesn't grow too quickly.
I fail to see why slower growth is a good thing?
42 matches
Mail list logo
