So in your example I would expect that you would configure bucket B to be sent to the couchbase-elasticsearch plugin.
I would then expect searches to be sent directly to the elasticsearch index. The results of this search would be document IDs, and any other fields you chose to "store" in the Elasticsearch index. These stored fields could include attachment names. Now that you have the matching document IDs (and possibly also attachment filenames) you could make requests to the gateway to retrieve the documents and/or their attachments. Some of your wording still confuses me. You would choose to index bucket B, because it contains the data you want to search. To actually retrieve the attachment content, you have to make a request to bucket A (or the gateway) because bucket A is the only place the attachments are stored. marty On Wed, Jun 4, 2014 at 9:49 AM, CouchbaseLover <[email protected]> wrote: > 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]> >> 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]. >>> 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 > <https://groups.google.com/d/msgid/mobile-couchbase/4b010b2b-be0e-4eab-a4f6-a68838e702a9%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/CAE2t7botqGNZ6%3DA-Rvt%3D53ZDEgZU1ecgg4Z3gOLYAN0rtL07dw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
