gravitystorm left a comment (openstreetmap/openstreetmap-website#6399)
> I rebased the PR
Thanks.
> change the limit to 1_000_000
This needs some substantial and convincing supporting use-cases. A million
UTF-8 characters is an awful lot of text.
The UserPreferences system is designed for storing key-value pairs, not for
storing either entire works of Shakespeare or arbitrary binary blobs
masquerading in a pseudo UTF-8 character encoding.
Storing ~1MB of data in a single value has some serious knock-on effects. You
can't download part of a value, so every client that needs any iota of the
information stored in that value needs to download the entire value (think e.g.
mobile connectivity). Every upload has the same problem - you can't upload part
of a value. If we start storing ~MB values, someone will then ask for range
requests within the value, or to paginate the values, or something similar.
```
GET /api/0.6/user/preferences/my_key_name?character_range=600000-600010 # n.b.
not a serious proposal
```
Also, if you need ~MB values in keys, and multiple apps using multiple keys
start storing multi-megabytes of "preferences", then the base `GET
/api/0.6/user/preferences` call becomes unusable for most clients.
If you're storing structured data hidden within a value of a key, which is
itself part of a structured document, that's some inception-nesting and again
suggests this isn't a good idea.
So let's see some use-cases, and figure out a better option. I don't want to
say that the current 255 limit is unchangeable, but the limit exists for
various reasons, and aren't just there to get in the way or to be worked around.
--
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/openstreetmap-website/pull/6399#issuecomment-3714407205
You are receiving this because you are subscribed to this thread.
Message ID:
<openstreetmap/openstreetmap-website/pull/6399/[email protected]>
_______________________________________________
rails-dev mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/rails-dev
