[OSM-dev] 0.5 API: /api/0.5/user/preferences, values truncated to 256 chars

[Stefan de Konink]

Matt Amos wrote:
> On Tue, Nov 25, 2008 at 6:34 PM, Stefan de Konink <stefan at konink.de> wrote:
>> Matt Amos wrote:
>>> do you think it would be motivating for all the
>>> volunteers working on the editor and server code if we set a deadline?
>> I think so; it would make people live to a date, and see something big
>> happening. Would not only be good for the community not only for developers.
> 
> i think the problem might be *agreeing* about the deadline in the
> first place :-)

Then it might be better to never use any argument as 'wait till 0.6' 
because it could take till March... It might be even reasonable to 
migrate in 4 months.

>> The point was that I had limited it to 255 too, until I saw my inserts
>> failing. So that could be two things, XML encoding problems, or something
>> else. Never the less 255 seems enough to me too.
> 
> does monetDB treat strings as byte sequences?

I only know how it works a bit under the surface, basically VARCHAR(255) 
would lets say be a fixed limit of 255 characters. That have an hash 
table over them. So basically every value that is placed in a column is 
an ObjectID pointing to the Hash (IIRC) this implements automatic 
indexing (and deduplication of string values). But I am not a developer 
of the database, only an annoying (yes there too ;) user.

>>> the exception is the note: key, which i've quite often wished were
>>> longer. we now have things like openstreetbugs for some of these,
>>> though.
>> Just introduce an extra table; that stores the <note></note> field?
> 
> ah, but that would require "blessing" the note tag, or stopping it
> being a tag. i think a better solution is an separate (or at least
> independent) database like openstreetbugs which is designed for
> note-taking and has an API that editors can access. maybe
> openstreetnotes?

I love the layers aspect. So I would say yes right away to that :) Just 
requires smart editors that can gather and update multiple sources.



Stefan