Blobs content type is not being read
Rudiksz opened this issue · comments
The content type of a Blob is not being parsed correctly.
in lib/src/Blob.dart
Blob._fromMap(Map<String, dynamic> map) {
print(map);
this._contentType = map["contentType"];
this._digest = map["digest"];
this._length = map["length"];
}
While the result map uses the key "content_type". This causes blobs to be deleted when saving the document again, because contentType is null. Probably because even though all other fields are correct, including the data, couchbase thinks there's no attachment and just deletes the entry altogether.
Replacing the line with the one below, fixes the problem of the blobs being deleted on subsequent saves.
this._contentType = map["content_type"];
There's another instance in Document.dart where the wrong index is used, but I haven't tested that.
Blobs aren't fully supported because they are loaded into memory which causes issues with memory management and would need to be fetched over the channel every time from the originating object because they aren't technically stored in the object. We used to use them as well but have since switched to using minio instead and store the url since the max size of a blob is 20MB anyways it limits what you can do. If you have a solution feel free to do a pull request and I will roll it out in a release as long as long as it is fully tested and is a clean solution. Thank you for catching the issue.
I'm using them to attach logos and avatars to some of my documents. Max 50KB images. Couchbase should be able to server these and Flutter should be able to handle storing a few of these in memory.
For larger documents I was playing with the idea to have some kind of integration with the google docs api, to avoid having to store the data, but I'll look into minio too. That's for a "nice to have" feature anyway.
Though, wouldn't using a service that requires internet defeat the purpose of using an offline first approach?
Shouldn't have any issues with 50k sizes or from the code I looked at. So just need to make sure the keys are correct and everything works on both android and iOS and we should be fine.
So I looked at the code and I think what is actually happening is that the document is being saved and it is passing an empty byte array for the data or something like that. By changing the key value like you did the code skips updating the blob and instead preserves it.
I'm labeling this as an enhancement because this is specific to supporting Blobs in queries which is not currently supported.
Documents should typically be updated by getting the document by id through the database and not queries because conflict resolution cannot be supported through this method of updating. Will need to verify this way of updating but I believe this may be treated as a document creation and not update.
Documents should typically be updated by getting the document by id through the database and not queries because conflict resolution cannot be supported through this method of updating. Will need to verify this way of updating but I believe this may be treated as a document creation and not update.
So it looks like it does create a new revision and add it to the history. I didn't verify that sync gateway treats it any differently but looks like another method of updating to me and I don't think it will cause issues unless something different happens in sync gateway like not passing the old doc or something like that.
Version 2.7.1+5 should have the fix for this