You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by "Johs. E" <jo...@b2w.com> on 2015/09/04 14:21:12 UTC
CouchDB _rewrite
Fellow CouchDB enthusiasts,
Let me quote a dialogue I had the other day with a colleague on Couchapps and _rewrite:
> > I would like to know what is so horrible with the vhost/rewrite of CouchDB
> You must concentrate all rules in one place, that is totally out of idea ‘one app – one ddoc’
> Capturing mechanics is outrageously ugly and limiting. You can‘t capture on query, only on path, and in very limiting manner. Obsolete for at least 15 years.
> Rule lists are flat – they must be trees, since it‘s json, not SQL table of directory with files.
> It‘s all very brittle, error prone and imposes all possible hurdles during debug – no err messages, no log, no validator.
> And most important: it creates illusion, that it can fit everything – but it only fits small static-like sites.
> > Is it something that could be fed to the developers?
>
> Don‘t think anybody of them is interested. This functions assumed obsolete or impractical by the vast majority of community, as I see. And I agree with them.
Still with its limitations, I love _rewrite
You direct the vhost to db/_design/api/_rewrite
using so-called “unsafe” rewrites, you create an API for your many databases and their couchapps there.
It works beautifully.
That is at Cloudant. I think I learned from an earlier discussion that the lack of a “default vhost” is a problem outside Cloudant.
Now Cloudant does not offer SSL unless you enter into a relationship with your local IBM organization and buy a dedicated cluster under a std IBM contract, so
Of course I would like to see a better rewrite function, my priority would be
A tree structure of rules
Capture query in the “to”
That would be a great enhancement to go with version 2.0
br
Johs
Re: CouchDB _rewrite
Posted by Johs Ensby <jo...@b2w.com>.
Hi Paul,
you're right, Cloudant has SSL connections for clients to the *.cloudant.com <http://cloudant.com/> domains.
and I guess in the context of vhost/_rewrite this could be used for one domain per Cloudant account.
It would be nice if Cloudant could offer the opportunity to have SSL certs on users own domains, since the step up from the metered services to dedicated cluster is too hight right now.
br
johs
> On 6. sep. 2015, at 21.40, Paul Davis <pa...@gmail.com> wrote:
>
> On Fri, Sep 4, 2015 at 7:21 AM, Johs. E <jo...@b2w.com> wrote:
>> Fellow CouchDB enthusiasts,
>>
>> Let me quote a dialogue I had the other day with a colleague on Couchapps and _rewrite:
>>
>>>> I would like to know what is so horrible with the vhost/rewrite of CouchDB
>>> You must concentrate all rules in one place, that is totally out of idea ‘one app – one ddoc’
>>> Capturing mechanics is outrageously ugly and limiting. You can‘t capture on query, only on path, and in very limiting manner. Obsolete for at least 15 years.
>>> Rule lists are flat – they must be trees, since it‘s json, not SQL table of directory with files.
>>> It‘s all very brittle, error prone and imposes all possible hurdles during debug – no err messages, no log, no validator.
>>> And most important: it creates illusion, that it can fit everything – but it only fits small static-like sites.
>>>> Is it something that could be fed to the developers?
>>>
>>> Don‘t think anybody of them is interested. This functions assumed obsolete or impractical by the vast majority of community, as I see. And I agree with them.
>>
>> Still with its limitations, I love _rewrite
>> You direct the vhost to db/_design/api/_rewrite
>> using so-called “unsafe” rewrites, you create an API for your many databases and their couchapps there.
>> It works beautifully.
>> That is at Cloudant. I think I learned from an earlier discussion that the lack of a “default vhost” is a problem outside Cloudant.
>> Now Cloudant does not offer SSL unless you enter into a relationship with your local IBM organization and buy a dedicated cluster under a std IBM contract, so
>>
>
> Just to clarify, we don't offer hosting custom SSL certs for
> non-Cloudant domains unless you have dedicated cluster. Of course we
> have SSL connections for clients to the *.cloudant.com domains.
>
> I was just really confused when I read that at first. :D
>
>> Of course I would like to see a better rewrite function, my priority would be
>> A tree structure of rules
>> Capture query in the “to”
>> That would be a great enhancement to go with version 2.0
>>
>> br
>> Johs
>>
Re: CouchDB _rewrite
Posted by Johs Ensby <jo...@b2w.com>.
Hi Paul,
you're right, Cloudant has SSL connections for clients to the *.cloudant.com <http://cloudant.com/> domains.
and I guess in the context of vhost/_rewrite this could be used for one domain per Cloudant account.
It would be nice if Cloudant could offer the opportunity to have SSL certs on users own domains, since the step up from the metered services to dedicated cluster is too hight right now.
br
johs
> On 6. sep. 2015, at 21.40, Paul Davis <pa...@gmail.com> wrote:
>
> On Fri, Sep 4, 2015 at 7:21 AM, Johs. E <jo...@b2w.com> wrote:
>> Fellow CouchDB enthusiasts,
>>
>> Let me quote a dialogue I had the other day with a colleague on Couchapps and _rewrite:
>>
>>>> I would like to know what is so horrible with the vhost/rewrite of CouchDB
>>> You must concentrate all rules in one place, that is totally out of idea ‘one app – one ddoc’
>>> Capturing mechanics is outrageously ugly and limiting. You can‘t capture on query, only on path, and in very limiting manner. Obsolete for at least 15 years.
>>> Rule lists are flat – they must be trees, since it‘s json, not SQL table of directory with files.
>>> It‘s all very brittle, error prone and imposes all possible hurdles during debug – no err messages, no log, no validator.
>>> And most important: it creates illusion, that it can fit everything – but it only fits small static-like sites.
>>>> Is it something that could be fed to the developers?
>>>
>>> Don‘t think anybody of them is interested. This functions assumed obsolete or impractical by the vast majority of community, as I see. And I agree with them.
>>
>> Still with its limitations, I love _rewrite
>> You direct the vhost to db/_design/api/_rewrite
>> using so-called “unsafe” rewrites, you create an API for your many databases and their couchapps there.
>> It works beautifully.
>> That is at Cloudant. I think I learned from an earlier discussion that the lack of a “default vhost” is a problem outside Cloudant.
>> Now Cloudant does not offer SSL unless you enter into a relationship with your local IBM organization and buy a dedicated cluster under a std IBM contract, so
>>
>
> Just to clarify, we don't offer hosting custom SSL certs for
> non-Cloudant domains unless you have dedicated cluster. Of course we
> have SSL connections for clients to the *.cloudant.com domains.
>
> I was just really confused when I read that at first. :D
>
>> Of course I would like to see a better rewrite function, my priority would be
>> A tree structure of rules
>> Capture query in the “to”
>> That would be a great enhancement to go with version 2.0
>>
>> br
>> Johs
>>
Re: CouchDB _rewrite
Posted by Paul Davis <pa...@gmail.com>.
On Fri, Sep 4, 2015 at 7:21 AM, Johs. E <jo...@b2w.com> wrote:
> Fellow CouchDB enthusiasts,
>
> Let me quote a dialogue I had the other day with a colleague on Couchapps and _rewrite:
>
>> > I would like to know what is so horrible with the vhost/rewrite of CouchDB
>> You must concentrate all rules in one place, that is totally out of idea ‘one app – one ddoc’
>> Capturing mechanics is outrageously ugly and limiting. You can‘t capture on query, only on path, and in very limiting manner. Obsolete for at least 15 years.
>> Rule lists are flat – they must be trees, since it‘s json, not SQL table of directory with files.
>> It‘s all very brittle, error prone and imposes all possible hurdles during debug – no err messages, no log, no validator.
>> And most important: it creates illusion, that it can fit everything – but it only fits small static-like sites.
>> > Is it something that could be fed to the developers?
>>
>> Don‘t think anybody of them is interested. This functions assumed obsolete or impractical by the vast majority of community, as I see. And I agree with them.
>
> Still with its limitations, I love _rewrite
> You direct the vhost to db/_design/api/_rewrite
> using so-called “unsafe” rewrites, you create an API for your many databases and their couchapps there.
> It works beautifully.
> That is at Cloudant. I think I learned from an earlier discussion that the lack of a “default vhost” is a problem outside Cloudant.
> Now Cloudant does not offer SSL unless you enter into a relationship with your local IBM organization and buy a dedicated cluster under a std IBM contract, so
>
Just to clarify, we don't offer hosting custom SSL certs for
non-Cloudant domains unless you have dedicated cluster. Of course we
have SSL connections for clients to the *.cloudant.com domains.
I was just really confused when I read that at first. :D
> Of course I would like to see a better rewrite function, my priority would be
> A tree structure of rules
> Capture query in the “to”
> That would be a great enhancement to go with version 2.0
>
> br
> Johs
>
Re: CouchDB _rewrite
Posted by Paul Davis <pa...@gmail.com>.
On Fri, Sep 4, 2015 at 7:21 AM, Johs. E <jo...@b2w.com> wrote:
> Fellow CouchDB enthusiasts,
>
> Let me quote a dialogue I had the other day with a colleague on Couchapps and _rewrite:
>
>> > I would like to know what is so horrible with the vhost/rewrite of CouchDB
>> You must concentrate all rules in one place, that is totally out of idea ‘one app – one ddoc’
>> Capturing mechanics is outrageously ugly and limiting. You can‘t capture on query, only on path, and in very limiting manner. Obsolete for at least 15 years.
>> Rule lists are flat – they must be trees, since it‘s json, not SQL table of directory with files.
>> It‘s all very brittle, error prone and imposes all possible hurdles during debug – no err messages, no log, no validator.
>> And most important: it creates illusion, that it can fit everything – but it only fits small static-like sites.
>> > Is it something that could be fed to the developers?
>>
>> Don‘t think anybody of them is interested. This functions assumed obsolete or impractical by the vast majority of community, as I see. And I agree with them.
>
> Still with its limitations, I love _rewrite
> You direct the vhost to db/_design/api/_rewrite
> using so-called “unsafe” rewrites, you create an API for your many databases and their couchapps there.
> It works beautifully.
> That is at Cloudant. I think I learned from an earlier discussion that the lack of a “default vhost” is a problem outside Cloudant.
> Now Cloudant does not offer SSL unless you enter into a relationship with your local IBM organization and buy a dedicated cluster under a std IBM contract, so
>
Just to clarify, we don't offer hosting custom SSL certs for
non-Cloudant domains unless you have dedicated cluster. Of course we
have SSL connections for clients to the *.cloudant.com domains.
I was just really confused when I read that at first. :D
> Of course I would like to see a better rewrite function, my priority would be
> A tree structure of rules
> Capture query in the “to”
> That would be a great enhancement to go with version 2.0
>
> br
> Johs
>
Re: CouchDB _rewrite
Posted by "Johs. E" <jo...@b2w.com>.
Thanks Joan,
we will prepare a strong case for it — probably needs to be part of a the “couchapp story” discussion that we had a while ago
johs
> On 04 Sep 2015, at 19:01, Joan Touzet <wo...@apache.org> wrote:
>
> Proedurally, CouchDB 2.0 is effectively in feature freeze - we need to
> get it out the door, it is far overdue.
>
> Looking at changing basic functionality like _rewrite can come after
> 2.0 is done, in the 3.0 timeframe.
>
> -Joan
>
> ----- Original Message -----
>> From: "Johs. E" <jo...@b2w.com>
>> To: "dev@couchdb.apache.org Developers" <de...@couchdb.apache.org>
>> Cc: marketing@couchdb.apache.org
>> Sent: Friday, September 4, 2015 8:21:12 AM
>> Subject: CouchDB _rewrite
>>
>> Fellow CouchDB enthusiasts,
>>
>> Let me quote a dialogue I had the other day with a colleague on
>> Couchapps and _rewrite:
>>
>>>> I would like to know what is so horrible with the vhost/rewrite
>>>> of CouchDB
>>> You must concentrate all rules in one place, that is totally out of
>>> idea ‘one app – one ddoc’
>>> Capturing mechanics is outrageously ugly and limiting. You can‘t
>>> capture on query, only on path, and in very limiting manner.
>>> Obsolete for at least 15 years.
>>> Rule lists are flat – they must be trees, since it‘s json, not SQL
>>> table of directory with files.
>>> It‘s all very brittle, error prone and imposes all possible hurdles
>>> during debug – no err messages, no log, no validator.
>>> And most important: it creates illusion, that it can fit everything
>>> – but it only fits small static-like sites.
>>>> Is it something that could be fed to the developers?
>>>
>>> Don‘t think anybody of them is interested. This functions assumed
>>> obsolete or impractical by the vast majority of community, as I
>>> see. And I agree with them.
>>
>> Still with its limitations, I love _rewrite
>> You direct the vhost to db/_design/api/_rewrite
>> using so-called “unsafe” rewrites, you create an API for your many
>> databases and their couchapps there.
>> It works beautifully.
>> That is at Cloudant. I think I learned from an earlier discussion
>> that the lack of a “default vhost” is a problem outside Cloudant.
>> Now Cloudant does not offer SSL unless you enter into a relationship
>> with your local IBM organization and buy a dedicated cluster under a
>> std IBM contract, so
>>
>> Of course I would like to see a better rewrite function, my priority
>> would be
>> A tree structure of rules
>> Capture query in the “to”
>> That would be a great enhancement to go with version 2.0
>>
>> br
>> Johs
>>
>>
Re: CouchDB _rewrite
Posted by "Johs. E" <jo...@b2w.com>.
Thanks Joan,
we will prepare a strong case for it — probably needs to be part of a the “couchapp story” discussion that we had a while ago
johs
> On 04 Sep 2015, at 19:01, Joan Touzet <wo...@apache.org> wrote:
>
> Proedurally, CouchDB 2.0 is effectively in feature freeze - we need to
> get it out the door, it is far overdue.
>
> Looking at changing basic functionality like _rewrite can come after
> 2.0 is done, in the 3.0 timeframe.
>
> -Joan
>
> ----- Original Message -----
>> From: "Johs. E" <jo...@b2w.com>
>> To: "dev@couchdb.apache.org Developers" <de...@couchdb.apache.org>
>> Cc: marketing@couchdb.apache.org
>> Sent: Friday, September 4, 2015 8:21:12 AM
>> Subject: CouchDB _rewrite
>>
>> Fellow CouchDB enthusiasts,
>>
>> Let me quote a dialogue I had the other day with a colleague on
>> Couchapps and _rewrite:
>>
>>>> I would like to know what is so horrible with the vhost/rewrite
>>>> of CouchDB
>>> You must concentrate all rules in one place, that is totally out of
>>> idea ‘one app – one ddoc’
>>> Capturing mechanics is outrageously ugly and limiting. You can‘t
>>> capture on query, only on path, and in very limiting manner.
>>> Obsolete for at least 15 years.
>>> Rule lists are flat – they must be trees, since it‘s json, not SQL
>>> table of directory with files.
>>> It‘s all very brittle, error prone and imposes all possible hurdles
>>> during debug – no err messages, no log, no validator.
>>> And most important: it creates illusion, that it can fit everything
>>> – but it only fits small static-like sites.
>>>> Is it something that could be fed to the developers?
>>>
>>> Don‘t think anybody of them is interested. This functions assumed
>>> obsolete or impractical by the vast majority of community, as I
>>> see. And I agree with them.
>>
>> Still with its limitations, I love _rewrite
>> You direct the vhost to db/_design/api/_rewrite
>> using so-called “unsafe” rewrites, you create an API for your many
>> databases and their couchapps there.
>> It works beautifully.
>> That is at Cloudant. I think I learned from an earlier discussion
>> that the lack of a “default vhost” is a problem outside Cloudant.
>> Now Cloudant does not offer SSL unless you enter into a relationship
>> with your local IBM organization and buy a dedicated cluster under a
>> std IBM contract, so
>>
>> Of course I would like to see a better rewrite function, my priority
>> would be
>> A tree structure of rules
>> Capture query in the “to”
>> That would be a great enhancement to go with version 2.0
>>
>> br
>> Johs
>>
>>
Re: CouchDB _rewrite
Posted by Joan Touzet <wo...@apache.org>.
Proedurally, CouchDB 2.0 is effectively in feature freeze - we need to
get it out the door, it is far overdue.
Looking at changing basic functionality like _rewrite can come after
2.0 is done, in the 3.0 timeframe.
-Joan
----- Original Message -----
> From: "Johs. E" <jo...@b2w.com>
> To: "dev@couchdb.apache.org Developers" <de...@couchdb.apache.org>
> Cc: marketing@couchdb.apache.org
> Sent: Friday, September 4, 2015 8:21:12 AM
> Subject: CouchDB _rewrite
>
> Fellow CouchDB enthusiasts,
>
> Let me quote a dialogue I had the other day with a colleague on
> Couchapps and _rewrite:
>
> > > I would like to know what is so horrible with the vhost/rewrite
> > > of CouchDB
> > You must concentrate all rules in one place, that is totally out of
> > idea ‘one app – one ddoc’
> > Capturing mechanics is outrageously ugly and limiting. You can‘t
> > capture on query, only on path, and in very limiting manner.
> > Obsolete for at least 15 years.
> > Rule lists are flat – they must be trees, since it‘s json, not SQL
> > table of directory with files.
> > It‘s all very brittle, error prone and imposes all possible hurdles
> > during debug – no err messages, no log, no validator.
> > And most important: it creates illusion, that it can fit everything
> > – but it only fits small static-like sites.
> > > Is it something that could be fed to the developers?
> >
> > Don‘t think anybody of them is interested. This functions assumed
> > obsolete or impractical by the vast majority of community, as I
> > see. And I agree with them.
>
> Still with its limitations, I love _rewrite
> You direct the vhost to db/_design/api/_rewrite
> using so-called “unsafe” rewrites, you create an API for your many
> databases and their couchapps there.
> It works beautifully.
> That is at Cloudant. I think I learned from an earlier discussion
> that the lack of a “default vhost” is a problem outside Cloudant.
> Now Cloudant does not offer SSL unless you enter into a relationship
> with your local IBM organization and buy a dedicated cluster under a
> std IBM contract, so
>
> Of course I would like to see a better rewrite function, my priority
> would be
> A tree structure of rules
> Capture query in the “to”
> That would be a great enhancement to go with version 2.0
>
> br
> Johs
>
>
Re: CouchDB _rewrite
Posted by Joan Touzet <wo...@apache.org>.
Proedurally, CouchDB 2.0 is effectively in feature freeze - we need to
get it out the door, it is far overdue.
Looking at changing basic functionality like _rewrite can come after
2.0 is done, in the 3.0 timeframe.
-Joan
----- Original Message -----
> From: "Johs. E" <jo...@b2w.com>
> To: "dev@couchdb.apache.org Developers" <de...@couchdb.apache.org>
> Cc: marketing@couchdb.apache.org
> Sent: Friday, September 4, 2015 8:21:12 AM
> Subject: CouchDB _rewrite
>
> Fellow CouchDB enthusiasts,
>
> Let me quote a dialogue I had the other day with a colleague on
> Couchapps and _rewrite:
>
> > > I would like to know what is so horrible with the vhost/rewrite
> > > of CouchDB
> > You must concentrate all rules in one place, that is totally out of
> > idea ‘one app – one ddoc’
> > Capturing mechanics is outrageously ugly and limiting. You can‘t
> > capture on query, only on path, and in very limiting manner.
> > Obsolete for at least 15 years.
> > Rule lists are flat – they must be trees, since it‘s json, not SQL
> > table of directory with files.
> > It‘s all very brittle, error prone and imposes all possible hurdles
> > during debug – no err messages, no log, no validator.
> > And most important: it creates illusion, that it can fit everything
> > – but it only fits small static-like sites.
> > > Is it something that could be fed to the developers?
> >
> > Don‘t think anybody of them is interested. This functions assumed
> > obsolete or impractical by the vast majority of community, as I
> > see. And I agree with them.
>
> Still with its limitations, I love _rewrite
> You direct the vhost to db/_design/api/_rewrite
> using so-called “unsafe” rewrites, you create an API for your many
> databases and their couchapps there.
> It works beautifully.
> That is at Cloudant. I think I learned from an earlier discussion
> that the lack of a “default vhost” is a problem outside Cloudant.
> Now Cloudant does not offer SSL unless you enter into a relationship
> with your local IBM organization and buy a dedicated cluster under a
> std IBM contract, so
>
> Of course I would like to see a better rewrite function, my priority
> would be
> A tree structure of rules
> Capture query in the “to”
> That would be a great enhancement to go with version 2.0
>
> br
> Johs
>
>