On Feb 26, 2013, at 14:54 , Troy Farrell <[email protected]> wrote:
> 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.) I think determining when CouchDB is *not* a good fit is crucial. I for one am not interested in unhappy users. Best Jan -- > > Troy > > On Mon, Feb 25, 2013 at 5:50 PM, Daniel Gonzalez <[email protected]>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 >>
