<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Thank you both.</div><div class="gmail_quote"><br></div><div class="gmail_quote">I agree to freeze the adapter's development until datasync is discussed.</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">comments inline</div><div class="gmail_quote"><br></div><div class="gmail_quote">2014-05-27 16:12 GMT+03:00 Lucas Holmquist <span dir="ltr"><<a href="mailto:lholmqui@redhat.com" target="_blank">lholmqui@redhat.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Cool Stuff, i will take a look</div>
<br><div><div class=""><div>On May 26, 2014, at 7:55 AM, Lukáš Fryč <<a href="mailto:lukas.fryc@gmail.com" target="_blank">lukas.fryc@gmail.com</a>> wrote:</div><br><blockquote type="cite"><div dir="ltr">Hey Tolis,<div>
<br></div><div>great job with the adapter!</div><div><br></div><div><br></div><div>a) remove()</div><div><br></div><div>since there are obviously many ways how to achieve "delete all docs",</div>
<div>I believe it's up to user to choose the way he wants the docs deleted<br></div><div>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?<br>
</div><div><br></div></div></blockquote></div></div></div></blockquote><div>+1 </div><div><br></div><div>investigation is needed to find out if there are any best practices</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div class=""><blockquote type="cite"><div dir="ltr"><div></div><div><br></div><div>b) Filtering</div><div><br></div><div>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.</div>
<div>We are also able to create temporary views, but that requires you to perform one additional POST request and it is costly.<br></div><div><br></div></div></blockquote></div></div></div></blockquote><div>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. </div>
<div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div class="">
<blockquote type="cite"><div dir="ltr"><div></div><div>Are we able to come up with a common view definition that would cover all the filtering capabilities - i.e. generic aerogear-filter view?</div>
<div>Something that user would define once and all cases would be covered.</div><div>I have not practically played with CouchDB, but according the docs it could be somehow possible.</div><div><br></div><div><br></div><div>
<br></div><div>Btw as I think about it, there might be lack of function for limiting what data to transfer. </div><div>i.e. Filtering API allows you to select just particular docs, but it does not help you to avoid what will be transferred.</div>
<div><br></div><div>All the Data Managers so far are local ones, CouchDB is a first one that actually transfers data from the wire.</div></div></blockquote><div><br></div></div><div>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.</div>
<div><br></div><div>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 </div><div class=""><div><br></div>
</div></div></div></blockquote><div>agreed<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br></blockquote></div><br></div></div>