Realistic number of attachments per database on CBL for Mac (and iOS)

[Brendan Duddridge]

Hi,

Given that I may have thousands of document attachments, does it make sense to store them as regular attachments in CouchBaseLite on iOS so they end up in the attachments folder next to the database? It could be a ton of files for a single folder to manage.

It would be difficult for a customer to be able to go to the Finder and find a file they wanted without navigating to it via the application. I know a lot of users just really like to have their files easily reachable in the Finder.

Also, what do you do about aliases to files? Do they still work with CBL? Can an attachment point to a file elsewhere on the disk in the Mac version?

Also, in my Mac app I have a "Show in Finder" button which takes the user directly to the file attachment. Currently with CBL this would just show them a .blob file I believe. I guess the only real way to handle that properly would be to have an Export function instead which would copy the file attachment out to a location of the user's choosing.

It would be nice to know what other users are doing to handle attachments. It would at least be nice to be able to specify sub-folders of the attachments folders so you could store attachments of different types in different folders. I like organization :-)

Thanks,

Brendan

[Jens Alfke]

On Jun 14, 2015, at 2:57 PM, Brendan Duddridge <bren...@gmail.com> wrote:

Given that I may have thousands of document attachments, does it make sense to store them as regular attachments in CouchBaseLite on iOS so they end up in the attachments folder next to the database? It could be a ton of files for a single folder to manage.

Thousands of files in a directory is no problem for HFS+.

It would be difficult for a customer to be able to go to the Finder and find a file they wanted without navigating to it via the application. I know a lot of users just really like to have their files easily reachable in the Finder.

Attachments are not meant to be user-visible files. The only reason attachments are stored as individual files at all is because it’s more efficient than putting them in the database.

The contents of the Attachments directory should never be modified by anything other than CBL. The only reason there’s an API to get the path to an attachment file is to support some system APIs (like ones for media playback) that require paths/URLs.

Also, what do you do about aliases to files? Do they still work with CBL? Can an attachment point to a file elsewhere on the disk in the Mac version?

No.

Also, in my Mac app I have a "Show in Finder" button which takes the user directly to the file attachment. Currently with CBL this would just show them a .blob file I believe. I guess the only real way to handle that properly would be to have an Export function instead which would copy the file attachment out to a location of the user's choosing.

That would be reasonable.

The Attachments directory is a content-addressable store. Attachments are named by their SHA-1 digests, and any attachments with the same contents in a database (even if they have different filenames or types) will be stored as the same file. That should make it clear why attachment files should never be modified!

—Jens

[Brendan Duddridge]

Hi Jens,

The Attachments directory is a content-addressable store. Attachments are named by their SHA-1 digests, and any attachments with the same contents in a database (even if they have different filenames or types) will be stored as the same file. That should make it clear why attachment files should never be modified!

Interesting. So if I allow the user to say, double-click on an attachment to view it in Preview (for say a PDF file), then they make a change to the file such as mark it up and then save it, what would happen in CBL? A user could theoretically just navigate directly to the file and edit it too. I couldn't stop that from happening. Would the sync system still push an update to the gateway with the changes?

Also, can you have multiple attachments with the same name? Currently my attachments are stored in separate folders, so you can have the same file name attached, but in different folders. But I'm seriously thinking about using CB attachments because then I don't have to worry about syncing file attachments independently of the database syncing.

Thanks!

Brendan

 

[Brendan Duddridge]

I think the answer to my second question is no, they have to be unique names. I'll have to unique the file names based on my Field's document ID for each record. Something like this:

"field-ABCDEF123456:Canadian Flag.png"

"field-ABCDEF123456:USA Flag.png"

"field-ABCDEF123456:British Flag.png"

and then even another set for a different field:

"field-XYZDEF123456:Canadian Flag.png"

"field-XYZDEF123456:USA Flag.png"

"field-XYZDEF123456:British Flag.png"

Even though the file names after the : are the same, they may be different files within the same record. For example, a smaller and larger version of the same file or even two different styles.

Then if the user deletes the file attachment Field object from their form, I can search all records for any attachments with names that start with that field's document id "field-ABCDEF123456" (or whatever) and delete the actual file. And I guess if they delete the record itself then CBL would handle deleting all the attachments for that record by itself I think.

Sorry if I'm spamming the list. Hopefully these questions are useful to others too. I don't have anyone else to work these things out and I find this helps just to type it out.

Thanks!

Brendan

[Jens Alfke]

On Jun 14, 2015, at 7:29 PM, Brendan Duddridge <bren...@gmail.com> wrote:

Interesting. So if I allow the user to say, double-click on an attachment to view it in Preview (for say a PDF file), then they make a change to the file such as mark it up and then save it, what would happen in CBL?

Bad things. CBL would still think it was the old attachment, even though its content no longer matches the digest in its filename. If it got pushed to a server or peer, the revision would contain the updated file even though it didn’t appear to be a new revision.

A user could theoretically just navigate directly to the file and edit it too. I couldn't stop that from happening.

That’s why you should never expose these files to the user, including by allowing other apps to open them as documents.

Would the sync system still push an update to the gateway with the changes?

No. CBL would have no idea that the file had changed. They’re supposed to be immutable.

Also, can you have multiple attachments with the same name?

In different documents, sure. Within a document, the attachment name is a key in a dictionary so it has to be unique.

—Jens