Thank you both.
I agree to freeze the adapter's development until datasync is discussed.
2014-05-27 16:12 GMT+03:00 Lucas Holmquist <lholmqui(a)redhat.com>:
Cool Stuff, i will take a look
On May 26, 2014, at 7:55 AM, Lukáš Fryč <lukas.fryc(a)gmail.com> wrote:
great job with the adapter!
since there are obviously many ways how to achieve "delete all docs",
I believe it's up to user to choose the way he wants the docs deleted
i.e. it could be up to Data Manager configuration whether data will be
deleted with or without a history loss (aka wipe out). wdyt?
investigation is needed to find out if there are any best practices
It would be pretty overwhelming for a user to create a view per particular
use of the filter() method, since it can have pretty arbitrary form.
We are also able to create temporary views, but that requires you to
perform one additional POST request and it is costly.
I think it's not overwelming for a user to create the view manually.
filtering is based on the key (simple or complex). IMO the ability
to search/filter different fields (which are not part of a complex key) and
create a view in each request, has no meaning in CouchDB. If a user has a
such requirement and data-queries are changing very often, then he should
consider using a different NoSQL db. CouchDB serves specific purposes and a
possible AeroGear JS CouchDB adapter should not offer functionality which
CouchDB is not designed to serve.
Temporary views are not a solution, for sure. They are one-off queries,
meaning that they are computed in each call (expensive and slow). CouchDB
docs suggest to use them for development purposes.
Are we able to come up with a common view definition that would cover
the filtering capabilities - i.e. generic aerogear-filter view?
Something that user would define once and all cases would be covered.
I have not practically played with CouchDB, but according the docs it
could be somehow possible.
Btw as I think about it, there might be lack of function for limiting what
data to transfer.
i.e. Filtering API allows you to select just particular docs, but it does
not help you to avoid what will be transferred.
All the Data Managers so far are local ones, CouchDB is a first one that
actually transfers data from the wire.
This is a concern i had when created the JIRA, This “adapter” might be
more appropriate for DataSync( or whatever we are calling it ). I know we
were looking at couchDB as a possible backend.
I’m wondering if we should hold off for now, and just keep DataManager
client side storage only for the moment. I think the fallback
functionality will be non-trivial
aerogear-dev mailing list