You just made everything much more clearer and answered a lot of questions
with that we should search seperately instead of "a single API".
But thing is, we still don't know how you can reach an attachments on a
"shadowed" bucket.
Ok il try to make this clear with an example.
1. We create a document with an attachment attached to it, that document
get's saved on Bucket A (the bucket that has all the sync gateway meta
data, "_sync" channels etc)
2. Trough shadowing we get the same document on Bucket B but without the
sync gateway meta data and still the attachment looking like this:
{
"_attachments": {
"xxxxx": {
"content_type": "image/jpeg",
"digest": "sha1-m0sikESS4UzfSh77N9yltJrjyRI=",
"length": 32419,
"revpos": 1,
"stub": true
}
3. Now we want to search for the "shadowed" document on Bucket B and find
attachments connected to it, how is this possible when shadowing does not
"replicate" the attachment connected to the document we are searching for,
we only see the attachment in Bucket A still with a
"_sync:att:sha1-m0sikESS4UzfSh77N9yltJrjyRI=" connected to it. Should we
not see the attachment in horseweb also and without the _sync?
Question: What's the point searching on Bucket B if it indirects searches
in Bucket A for the attachment, cause that's the only place it is stored?
CouchbaseLover
Den onsdagen den 4:e juni 2014 kl. 14:48:19 UTC+2 skrev Marty Schoch:
>
> I guess what I don't understand is how attachments relate to search here.
> Generally you search through documents, and get back matching document
> IDs. Those documents could have attachments, or not, it doesn't really
> matter.
>
> Are you saying you want to search through the content of the attachments?
> If so, then unless the attachments are also JSON you are right, it may not
> be easy to accomplish this.
>
> I think it may be that you are saying you can't accomplish what you want
> in a single call, because the documents, attachments, and search index are
> stored separately. That may be the case. I was assuming these would be
> done separately. First find the document IDs satisfying your search. Then
> separately acquire the documents and their attachments. Its possible a
> single API could consolidate this in the future, but often times you want
> to perform these steps separately anyway. For example, you might want to
> show the user search results, but not yet download attachments because they
> are large. Or maybe you want to lazily download them while the user is
> browsing the results. Having separate APIs gives you more flexibility here.
>
> Or possibly I'm still not getting what you're saying, in which case feel
> free to try and explain again.
>
> marty
>
>
> On Wed, Jun 4, 2014 at 3:14 AM, CouchbaseLover <[email protected]
> <javascript:>> wrote:
>
>> Hey! Thanks for caring, appreciate it! :)
>>
>> We have installed the Couchbase Elasticsearch Plugin and are up and
>> running with Elasticsearch. Still talking to the REST API to Couchbase SDK
>> though (can't remember if we should do the rest api to couchbase sdk or
>> elasticsearch (and then XDCR handles the rest, but that's fine cause you
>> can just read about that (good documentation on Elasticsearch and
>> Couchbase).
>>
>> My Question is however, how do i make our iOS app compatible with search
>> that has attachment's in them (Documents with attachments), we got
>> searching for documents to work a long time ago but with attachment it's
>> another story.
>> We are using shadowing and the other bucket do indeed get attachments as
>> well (if we want to search on the other bucket instead).
>>
>> I belive we have understood something fundamentally wrong with the whole
>> attachment stuff when it comes to searching. This is what we know:
>>
>> 1. The attachment linked to a document is in another document within the
>> database. (100%)
>> 2. The shadowing bucket does not receive the attachment documents but
>> only the documents that has a link to the attachment documents. (50%)
>> 3. You simply can't search and get attachments cause the attachment
>> filesystem is not reachable within the Couchbase SDK even though we search
>> in the non shadowing bucket(the bucket Couchbase Lite talks to) (10 %)
>>
>> I am sorry if this question is badly structured, it's very early here. We
>> can't wait to finally release our app that we have worked on for a long
>> time with Couchbase (since alpha) and congratulations again on 1.0, know
>> how hard you all have worked and great support.
>>
>>
>>
>> Den tisdagen den 3:e juni 2014 kl. 13:59:38 UTC+2 skrev Marty Schoch:
>>
>>>
>>> On Sun, Jun 1, 2014 at 6:34 PM, CouchbaseLover <[email protected]>
>>> wrote:
>>>
>>>> Thanks for the response and yes elasticsearch is the way to go i think,
>>>> but we can still not come up with any solution to handle attachments when
>>>> you search :(
>>>>
>>>>
>>> I'm not sure I fully understand. Could you explain more about how you
>>> would want it to work?
>>>
>>> Thanks,
>>> marty
>>>
>> --
>> 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] <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/mobile-couchbase/c2d730fe-eda3-4100-8ed5-52316b6dd795%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/mobile-couchbase/c2d730fe-eda3-4100-8ed5-52316b6dd795%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
--
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/4b010b2b-be0e-4eab-a4f6-a68838e702a9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
