<div dir="ltr">In the current implementation that would be considered one document.</div><div class="gmail_extra"><br><br><div class="gmail_quote">On 10 January 2014 16:29, Lucas Holmquist <span dir="ltr"><<a href="mailto:lholmqui@redhat.com" target="_blank">lholmqui@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">after playing with dan's server a bit, a question has popped up.<br>
<br>
lets say a user has 10 pieces of data, is this considered 1 "document", so like this:<br>
<br>
{<br>
id: "1234567890-0987654321-1234567890",<br>
rev: "12345678909876543456787654",<br>
content: [ { ... }, { ... } ] //make believe there are 10 things there<br>
}<br>
<br>
or is each piece of data a "document", and each piece has its own id and revision?<br>
<br>
I think i like the first option, but i'm not sure<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On Jan 9, 2014, at 11:07 AM, Summers Pittman <<a href="mailto:supittma@redhat.com">supittma@redhat.com</a>> wrote:<br>
<br>
> On Thu 09 Jan 2014 11:06:26 AM EST, Bruno Oliveira wrote:<br>
>> Makes sense, I think that’s a great start is to integrate your idea against what Dan already did to the server, into this way we can start to put together our puzzle.<br>
><br>
> Yup, just got Danbev's server up and running. I'll see what happens :)<br>
><br>
>><br>
>> --<br>
>> abstractj<br>
>><br>
>> On January 9, 2014 at 12:37:19 PM, Summers Pittman (<a href="mailto:supittma@redhat.com">supittma@redhat.com</a>) wrote:<br>
>>>> One of the things about using a provider that I don't like is the<br>
>>> "using a provider". One of the things I hope sync to become is a<br>
>>> collection of tools, utilities, and patterns that our developers<br>
>>> can<br>
>>> adopt to add in sync to their web apps without having to add extra<br>
>>> services like couch, pouch, etc and without having to significantly<br>
>>> alter their application.<br>
>>><br>
>>> HOWEVER, I am still reading up on / playing with Couch so don't<br>
>>> count<br>
>>> me out on thinking it is a good way to go forward; I just havn't seen<br>
>>> any code to get the feel for how it will interact inside of AeroGear.<br>
>>> It is entirely possible that it will be / can be one of the tools<br>
>>> that<br>
>>> we use for some of our sync solution.<br>
>><br>
><br>
><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>
<br>
<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>
</div></div></blockquote></div><br></div>