incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <bchesn...@gmail.com>
Subject Re: show/list
Date Thu, 14 Nov 2013 18:36:00 GMT
On Thu, Nov 14, 2013 at 7:30 PM, Brian Mitchell <brian@strmpnk.co> wrote:

> On Thu, Nov 14, 2013 at 1:24 PM, Benoit Chesneau <bchesneau@gmail.com>
> wrote:
> > On Thu, Nov 14, 2013 at 6:58 PM, Filippo Fadda <
> > filippo.fadda@programmazione.it> wrote:
> >
> >> Any application that uses CouchDB as a pure database doesn't need show
> and
> >> list handlers. They are simply useless, in fact I didn't implement (yet)
> >> them in ElephantOnCouch library because I don't see any use case for
> them.
> >> And I'm not sure if I will never implement them, probably not. If you
> are
> >> using Ruby, Python, PHP, you'll never produce HTML directly from
> CouchDB,
> >> because there are frameworks in plenty with template engines aimed to do
> >> the job.
> >> I don't know the history about show and list, but they remember me Lotus
> >> Domino. Of course you need them if you are developing a CouchApp.
> >>
> >> -Filippo
> >>
> >
> > On the contrary I think they are very useful for a database. A rather
> smart
> > way to  transform and query the data (doc or views).
> >
> > To do a bit of history the first proposal for them had only one handler
> > called "form", a way to format the data or send a form.  We settled on a
> > simpler form distinguishing docs and views and the way to handle them.
> > Sometime after you had the updates functions. They are not per see
> related
> > to the couchapps. You can do couchapps without them.
> >
> > On the other contrary lists and shows are a way to handle in memory on
> the
> > server side the results you fetch and provides new results depending on
> the
> > params you pass to the URL. All results can the be streamed to the
> client.
> > They can replace in some cases the queries you can do on some dbs like
> the
> > relational db or some document databases with more capabilities of query
> by
> > default. After all most of a SQL query is handled in memory.
> >
> > But actually they have their caveats. They can be slow due to the way the
> > JS engine work. The way we can improve this is known (in fact there
> aremany
> > different way: improving the messages between erlang and js, adding a
> DSL,
> > using a native language..). The other thing that should be improved is
> the
> > way the lists are working. For now we can't access to more than one view
> > (or secondary index) in a list which means we can't do yet complex
> queries
> > based on multiple index(views) like a relational or others databases like
> > datomic can do. Such change should be easy though.
> >
> > In short I don;t think we should deprecate such functions. We should on
> the
> > contrary improve them. And stop to associate them to "couchapps". They
> are
> > not.
>
> Do you think such features would fit inside an appropriately crafted
> plugin system?
>

imo such functions should be a core features for the reason above. A
database without transformation and query capabilities is not enough .
RDBMS have also such features (functions, triggers), so why not couchdb.
Also if we improve them we can't do it without having to adapt a little the
core I thik...

However the couchapp part (rewrites, vhosts and page display) could be a
plugin. This is not a function related to the data an I can completely
understand that some want to disable it.

- benoit

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