couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Goodall <matt.good...@gmail.com>
Subject Re: 0.11.x futon storage
Date Thu, 25 Feb 2010 10:44:35 GMT
On 25 February 2010 10:31, Matt Goodall <matt.goodall@gmail.com> wrote:

> On 23 February 2010 16:57, Matt Goodall <matt.goodall@gmail.com> wrote:
>
>> On 23 February 2010 16:35, Matt Goodall <matt.goodall@gmail.com> wrote:
>>
>>> On 23 February 2010 16:20, Christopher Lenz <cmlenz@gmx.de> 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.
>>
>
> I'm going to add a 0.11 ticket for this, for now. I honestly don't think
> 0.11 should go out while it does this and I'm worried it will get forgotten
> otherwise.
>

COUCHDB-671


>
> - Matt
>
>
>> 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
>>
>>
>

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