couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Goodall <>
Subject Re: 0.11.x futon storage
Date Tue, 23 Feb 2010 16:57:40 GMT
On 23 February 2010 16:35, Matt Goodall <> wrote:

> On 23 February 2010 16:20, Christopher Lenz <> wrote:
>> Hi Matt,
>> On 23.02.2010, at 14:25, Matt Goodall wrote:
>> > 2. Implicit type conversion. Doc attribute values are now implicitly
>> > converted to some type of Futon's choosing. I'm guessing this is
>> deliberate
>> > but, IMHO, it's just awful. It's easy to come up with contrived
>> examples,
>> > e.g. try changing "1" to 1 or changing "[]" to "[100]", but I managed to
>> end
>> > up with a {} getting stored as a string somehow (although I can't repeat
>> it
>> > again) and it broke my application.
>> The motivation for this was to make editing text less painful. Not having
>> to escape quotes and line breaks means it's now actually possible to edit
>> fields containing longer strings without pulling your hair out.
>> The implementation is simple: Anything that doesn't parse as valid JSON is
>> automatically treated as a string. I'm not going to claim that that this
>> approach is perfect, and there are certainly cases where it's unexpected or
>> annoying.
>> Just saying that IMHO there is a pretty large benefit to this approach
>> when trying to edit text fields.
> OK, that's a good point. I don't dump blocks of text into couchdb often so
> I hadn't considered that.
> I'm still not sure how I managed to accidentally convert {} to "{}" but it
> had me totally confused. I'd just made a change to the application code and
> I normally trust CouchDB a lot more than me ;-).
> I'm running 0.11.x on my machines now so I'll see how I get on. It
> certainly caused me some surprise and pain so far but perhaps I was just
> unlucky.
Chris, you're right it is nicer for long text. :)

One immediate problem is that for small strings (less than 60 chars) it uses
an input field and replaces line breaks with spaces. Perhaps it should
always use a textarea? One of those autoexpanding ones might work nicely. A
special key binding, say Shift+Enter, to leave and close the field would
nice as we'd lose <enter> and <tab>.

However, even using a textarea, isn't there a danger of changing the line
break characters? e.g. changing \r\n to \n.

- Matt

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message