Hi Jens,
Thank you so much for your answer. Sorry for this long post, but its with
good intentions.
Well, I said "basically there's nothing in the sync function" because I
wasn't worrying about it at that point that much, but if I am honest with
you I did try as well playing around with the channels before asking here.
See my latest sync function had:
function(doc) {
channel(doc.channels);
if(doc.type == "contactInfo"){
channel("public");
access(doc.username, "public");
} }
And it still wasn't working. But after I read your answer, I was feeling
more confident, so I went to review my code, again and.. Can you find the
mistake: ?
+ (NSString*) type{ return @"contacInfo"; }
Yes, look again. Nooo!! missing a "t" !! damn it :-)
BUT, this was just one of the many tests I was doing while trying to make
the sync work. So before you stop reading this:
Yes, I think as well that this situation (not the missing "t", but the
channel thing) is unexpected: however, I think this is more a documentation
issue than a design issue (I'm totally fine assigning a channel to a
document, as long as I know I really have to in order for it to sync).
I think the main problem is that this is explained just later on, in the
channel section of the sync gateway, so one can't learn "linearly"
following the guide from beginning to end. I know there's a thin / blurry
line between where to document somethings that are related both to
couchbase lite and the replication sync gateway. But if you agree with me,
here's is my opinion on where, how and why the documentation can be
improved:
The documentation says right in the beginning
<http://developer.couchbase.com/mobile/develop/guides/couchbase-lite/native-api/replication/index.html>
of the replication topic:
"The application code doesn't have to pay attention to the details: it just
knows that *when it makes changes to the local database they will
eventually be uploaded to the server, and when changes occur on the server
they will eventually be downloaded to the local database*. The app's job is
to make the UI reflect what's in the local database, and to reflect user
actions by making changes to local documents. "
Later on, the it mentions channels again, but this time inside the *
*Filters** topic:
A special type of filter used with the Couchbase Sync Gateway is the set
of *channels* that a pull replication will download from. It's also
possible to limit a replication to an explicit set of document IDs.
I didn't want to filter anything - but just get everything owned by that
user. Still, I was changing a document, but I wasn't getting it back (even
without setting up "filters", and even after using the same document ID).
If we follow this line of thought, seeing the replication as purely
self-contained mechanism to get an identical copy of the local database
everywhere, what I write on the "local" database should be always visible
from the app's perspective no matter if it originated locally (initWithID),
or if it came after a sync (to the local database), just like you said. So
I agree with you that its kind of misleading.
Of course, once you know how it works, it becomes "obvious", but "obvious"
is context-dependent and I think the main goal of the guides is to be clear
for beginners on how to use the tool - so if you do agree with me, can we
please ask somebody to at least add a big bold note in the cb lite's
replication documentation, stating that: a document will *not* be actually
synchronised if it is not set to any channel !? Okay, the sync gateway's
documentation makes this much more clear in the "channels" section (but
again, since this is a requirement, I think this should be clear right in
the beginning / introduction).
I don't know the internals of the project's syncing to give an opinion on
its design or gw's defaults > so its more up to you whether to change that
or the documentation. Either way I'd say its an improvement.
BR,
Thiago
On Monday, September 29, 2014 7:40:33 PM UTC+2, Jens Alfke wrote:
>
>
> On Sep 29, 2014, at 5:25 AM, Thiago Alencar <[email protected]
> <javascript:>> wrote:
>
> This document is newer, so I believe sync gateway will make this the
> winning revision from the conflict
>
>
> That's correct as long as by "newer" you mean "has more revisions" (i.e.
> higher generation count) There isn't any chronological timestamp on a
> document.
>
> After logging in, I first wait for the replication to complete, and just
> then I call [database existingDocumentWithID], in the hope that now I'll
> get the document instead of creating a new one.
> But no, I'm still not able to find the document and therefore I have no
> access to the "blobData" generated from the first device.
>
>
> Sounds like the document isn't in any channel your user account can read.
>
> And already to advance / confirm: right now I have basically nothing in my
> sync function
>
>
> The default sync function will assign the channels listed in the
> document's "channels" property. Since you didn't add such a property to
> your document, it's not in any channels. So unless you gave the user access
> to the wildcard "*" channel, the user won't be able to see the document,
> explaining your problem.
>
> There are many ways to solve this, depending on your apps' goals. A simple
> one is:
>
> - Define a private channel for each user, named something like "user-"
> + username
> - When creating a user account, add that channel to their
> admin_channels property
> - When creating documents, add a "channels" property whose value is an
> array containing the user's channel
>
>
> An even simpler one is to give every user account access to the "*"
> channel, although you'd only want that for experimentation, probably.
>
> This isn't the first time new developers have run into this, and I'm
> realizing that it's a problem with the Gateway's default settings — they
> create a situation where you can't read your own writes, which is
> unexpected.
>
> —Jens
>
--
You received this message because you are subscribed to the Google Groups
"Couchbase Mobile" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/mobile-couchbase/d683a45e-f2f6-45d5-90cd-425e93f89aad%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
