[aerogear-dev] aerogear-js CouchDB data-manager adapter
tolisemm at gmail.com
Wed May 28 03:19:18 EDT 2014
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 at redhat.com>:
> Cool Stuff, i will take a look
> On May 26, 2014, at 7:55 AM, Lukáš Fryč <lukas.fryc at gmail.com> wrote:
> Hey Tolis,
> great job with the adapter!
> a) remove()
> 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
> b) Filtering
> 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.
CouchDB 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 all
> 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
> aerogear-dev at lists.jboss.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the aerogear-dev