Re: [aerogear-dev] aerogear-js CouchDB data-manager adapter

Thank you both. I agree to freeze the adapter's development until datasync is discussed. comments inline 2014-05-27 16:12 GMT+03:00 Lucas Holmquist <lholmqui(a)redhat.com&gt;: Cool Stuff, i will take a look > > On May 26, 2014, at 7:55 AM, Lukáš Fryč <lukas.fryc(a)gmail.com&gt; 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? > > +1 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 > > agreed > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev