You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Matt Goodall <ma...@gmail.com> on 2010/02/23 14:25:43 UTC
0.11.x futon storage
Hi,
Not really sure if this is a dev or user questions as it's for an unreleased
version, but I have a couple of problems with Futon in the 0.11.x branch:
1. futon.storage. It isn't storing anything for me using
http://localhost:5984/. No cookies are set anymore. Most noticeable is that
the recent databases list is not updated and the key ascending/descending
flag for views is not remembered. I think this is because Storage is
including 'domain=localhost' but I'm not sure if dropping it will cause any
problem and haven't had chance to play yet.
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.
- Matt
Re: 0.11.x futon storage
Posted by Matt Goodall <ma...@gmail.com>.
On 23 February 2010 13:25, Matt Goodall <ma...@gmail.com> wrote:
> Not really sure if this is a dev or user questions as it's for an
> unreleased version, but I have a couple of problems with Futon in the 0.11.x
> branch:
>
> 1. futon.storage. It isn't storing anything for me using
> http://localhost:5984/. No cookies are set anymore. Most noticeable is
> that the recent databases list is not updated and the key
> ascending/descending flag for views is not remembered. I think this is
> because Storage is including 'domain=localhost' but I'm not sure if dropping
> it will cause any problem and haven't had chance to play yet.
>
It is the domain=localhost that is causing the problem.
The cookie domain was added when the cookie names were prefixed with the
port to allow multiple futons on the same server to have different defaults.
However, I don't think the domain is needed unless there's some
browser compatibility thing going on.
The usual reason for setting the cookie's domain is to allow the cookie to
travel between domains with a common parent domain. I can't think of a
reason why Futon currently needs that capability and there's no
configuration to say what cookie domain to use, it just uses
location.hostname.
So, I think the domain can be removed from the cookie completely. It
certainly seems to work for Chromium, Firefox and Opera on localhost,
127.0.0.1 and wibble.wobble.com. Can't test on IE.
Ticket on its way shortly.
- Matt
Re: 0.11.x futon storage
Posted by Matt Goodall <ma...@gmail.com>.
On 25 February 2010 10:31, Matt Goodall <ma...@gmail.com> wrote:
> On 23 February 2010 16:57, Matt Goodall <ma...@gmail.com> wrote:
>
>> On 23 February 2010 16:35, Matt Goodall <ma...@gmail.com> wrote:
>>
>>> On 23 February 2010 16:20, Christopher Lenz <cm...@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
>>
>>
>
Re: 0.11.x futon storage
Posted by Matt Goodall <ma...@gmail.com>.
On 23 February 2010 16:57, Matt Goodall <ma...@gmail.com> wrote:
> On 23 February 2010 16:35, Matt Goodall <ma...@gmail.com> wrote:
>
>> On 23 February 2010 16:20, Christopher Lenz <cm...@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.
- 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
>
>
Re: 0.11.x futon storage
Posted by Matt Goodall <ma...@gmail.com>.
On 23 February 2010 16:35, Matt Goodall <ma...@gmail.com> wrote:
> On 23 February 2010 16:20, Christopher Lenz <cm...@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. 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
Re: 0.11.x futon storage
Posted by Matt Goodall <ma...@gmail.com>.
On 23 February 2010 16:20, Christopher Lenz <cm...@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.
- Matt
Re: 0.11.x futon storage
Posted by Christopher Lenz <cm...@gmx.de>.
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.
Cheers,
--
Christopher Lenz
cmlenz at gmx.de
http://www.cmlenz.net/
Re: 0.11.x futon storage
Posted by Matt Goodall <ma...@gmail.com>.
On 23 February 2010 13:34, Sebastian Cohnen
<se...@googlemail.com>wrote:
> 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.
>
> There is definitly something wrong. Using the green button next to the
> field, Futon saves the type correctly. When editing the field again, some
> kind of broken type conversion is going on (String to Integer e.g.). This
> only happens in the "Fields"-View.
>
> Maybe you should open a ticket for this issue.
Thanks for confirming the problem. I've added a ticket, see COUCHDB-667.
- Matt
Re: 0.11.x futon storage
Posted by Sebastian Cohnen <se...@googlemail.com>.
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.
There is definitly something wrong. Using the green button next to the field, Futon saves the type correctly. When editing the field again, some kind of broken type conversion is going on (String to Integer e.g.). This only happens in the "Fields"-View.
Maybe you should open a ticket for this issue.