incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stanley Iriele <siriele...@gmail.com>
Subject Re: show/list
Date Thu, 14 Nov 2013 19:00:44 GMT
I agree...but I like them where they are....you just use them as you see
fit..instead of going that route... Couchdb is a flexible datastore.. Some
people marry the trek database with rdbms database and start comparing
features of of "these databases with everything
On Nov 14, 2013 10:36 AM, "Benoit Chesneau" <bchesneau@gmail.com> wrote:

> 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