Fetching attachments on demand

35 views
Skip to first unread message

Brett Harrison

unread,
May 5, 2015, 1:45:20 PM5/5/15
to mobile-c...@googlegroups.com
As an optional feature, has it ever been considered to pulling attachments on demand?  And not pulling them during sync, or pulling them in a very low priority mode?  I know this kind of conflicts with offline operation, but I can see a use for it if a database grows large with attachments.

Sascha Lüdecke

unread,
May 5, 2015, 2:07:36 PM5/5/15
to mobile-c...@googlegroups.com, Brett Harrison
To put it even further, a way to prioritize documents for replication would be a more general way to control replication. A use case is to replicate key masterdata first, then normal data and then attachments.

Regards
Sascha

On May 5, 2015 7:45:20 PM GMT+02:00, Brett Harrison <brett.h...@zyamusic.com> wrote:
As an optional feature, has it ever been considered to pulling attachments on demand?  And not pulling them during sync, or pulling them in a very low priority mode?  I know this kind of conflicts with offline operation, but I can see a use for it if a database grows large with attachments.


--
Sascha Lüdecke
+49 179 9210765

Jens Alfke

unread,
May 5, 2015, 2:15:06 PM5/5/15
to mobile-c...@googlegroups.com

On May 5, 2015, at 10:45 AM, Brett Harrison <brett.h...@zyamusic.com> wrote:

As an optional feature, has it ever been considered to pulling attachments on demand?  And not pulling them during sync, or pulling them in a very low priority mode?  I know this kind of conflicts with offline operation, but I can see a use for it if a database grows large with attachments.

Yes, we've talked about this, but it hasn't been implemented. It would be a major win, but it also needs a fair amount of API — configuring which attachments should be lazy, requesting an attachment, monitoring download progress, canceling, etc.

—Jens

Jens Alfke

unread,
May 5, 2015, 2:16:28 PM5/5/15
to mobile-c...@googlegroups.com, Brett Harrison

On May 5, 2015, at 11:07 AM, Sascha Lüdecke <sas...@meta-x.de> wrote:

To put it even further, a way to prioritize documents for replication would be a more general way to control replication. A use case is to replicate key masterdata first, then normal data and then attachments. 

You can do this by having the server group the documents into channels according to those criteria, then having the client specify which channels to pull.

—Jens

Brett Harrison

unread,
May 5, 2015, 4:49:19 PM5/5/15
to mobile-c...@googlegroups.com
I am currently on the fence with either trying to implement this feature in couchbase lite or using couchbase lite + url links in the documents to pull attachments on demand.

What would be the minimum feature set that I could implement in couchbase lite that would be considered as the start of an API?  I would hope to avoid changing the sync gateway under a first implementation.

Jens Alfke

unread,
May 11, 2015, 12:39:32 PM5/11/15
to mobile-c...@googlegroups.com

On May 5, 2015, at 1:49 PM, Brett Harrison <brett.h...@zyamusic.com> wrote:

What would be the minimum feature set that I could implement in couchbase lite that would be considered as the start of an API?  I would hope to avoid changing the sync gateway under a first implementation.

W00t, that’t be great. And this wouldn’t require any changes to SG; the REST API is already flexible enough to download docs without attachments or attachments without docs.

It might be best to discuss design in the Github issue, so it’s easier to find & refer to later. The main issue for this is #79 (yeah, it’s been around a while!) I’ll info-dump some thoughts there … OK, done! Let the design commence.

—Jens
Reply all
Reply to author
Forward
0 new messages