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

[Lukáš Fryč]

He guys,

resurrecting this topic,

I wonder whether it would make sense to do PouchDB adapter,
which is client-side API-compatible version of CouchDB,
that can be synchronized against CouchDB (due to REST API compatibility).

Wdyt?

~ Lukas


On Wed, May 28, 2014 at 9:19 AM, tolis emmanouilidis <tolisemm at gmail.com>
wrote:

> 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 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?
>>
>> +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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140609/1cc72740/attachment.html