couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Troy Farrell <t...@entheossoft.com>
Subject Re: Ad-hoc filtering
Date Tue, 26 Feb 2013 13:54:33 GMT
It's probably not a popular opinion, but this application does not sound
well-suited for CouchDB.  If you are creating views all the time, using
them once and still downloading all the data for post-processing, then
something is clearly wrong.  We may be able to help you restructure the
data and views so you need fewer of them, but if you truly need lots of
dynamic queries, CouchDB may not be the best choice for your application.
 (I would love for someone on this list to tell me I'm wrong.)

Troy

On Mon, Feb 25, 2013 at 5:50 PM, Daniel Gonzalez <gonvaled@gonvaled.com>wrote:

> Hi,
>
> It is not possible for me to define and manage all possible views that my
> application needs. Each time that I need to access data with a new
> filtering mechanism I have to:
>
>    1. Check if that view, or a similar one, already exists. (How would I
>    call this if I had created this half a year ago?)
>    2. If it doesn't, I must create it (javascript, not my piece of cake. I
>    am most of the time in python land).
>    3. I have to push the new design doc to all my servers (did you also
>    push to that-server-that-you-never-use? Do you really need to push this
>    view to that server? I don't remember, really.)
>    4. I have to trigger the new view (which can take some time in databases
>    with lots of docs), in all servers.
>
> So now you need to filter for False instead of True? Great! Rinse and
> repeat! At the end of the day I end up with dozens of views, some of them
> outdated, which I am not using anymore, but I am unable to maintain.
>
> Besides, defining lots of views becomes impractical: the more views you
> have in a design doc, the longer it takes a refresh when the design doc is
> modified. And the more views, the more space the database uses.
>
> At some point this becomes very painful. Which means that for some data I
> just do client-filtering.
>
> Very often I must perform the following operations:
>
>    1. Access a view
>    2. Filter the documents in the view according to some criteria (which is
>    not supported by a view)
>    3. Paginate the resulting documents
>
> Since the filtering is done in the client, I am forced to get all
> documents. I will discard most of them, but since I do not know which ones,
> I still must get them all. This is very slow.
>
> Since for some data I do view-filtering, and for other data I do
> client-filtering, some operations are taking a very long time to complete,
> whereas others are completed very fast. Which is confusing for the user.
>
> It would be great if couchdb supported field filtering. For example I would
> pass a dictionary like this: { 'available' : true, 'user' : 'user1' } And I
> would get only the documents which satisfy the filter. Using a single view.
> A simple "is equal to" operation for the given fields would go a looong way
> to solve most of my filtering needs.
>
> The view engine would perform the standard indexing, and the filtering
> would be an extra layer (slowing things down a bit, probably). It would be
> a compromise between view indexing and client filtering.
>
> Does this mechanism already exist? Does it make sense? Would it ever be
> implemented?
>
> Thanks
> Daniel Gonzalez
>

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