+972 52-548-6969
RavenDB 4.0Attachments
I previously wrote about the new attachments feature in RavenDB 4.0. Now it is ready to be seen by outside eyes.
As you can see in the image on the right, documents can now have attached attachments (I’m sorry, couldn’t think about a better way to phrase this). This give you the ability to store binary data inside RavenDB, but not as some free floating value that has only very loose connection to the rest of the system. Those attachments are strongly tied to their parent document, and allow you to store related information easily and right next to the document.
That also means that you can take advantage of RavenDB’s ACID nature and actually make modifications to both attachments and documents at the same time. For example, consider the following code:
Here we get the user’s profile picture, generate a thumbnail from it and then associate both picture and thumbnail with the document, we are also updating the status of the user to indicate that they have a profile picture and then submit it all as one single transaction. That means that you don’t have to sync between different sources.
Attachments in RavenDB are also kept consistent through replication, so you won’t see partial results between nodes, and the attachments themselves are using de-duplication techniques to reduce the amount of storage that we take.
I’m really happy with this feature.
More posts in "RavenDB 4.0" series:
- (30 Oct 2017) automatic conflict resolution
- (05 Oct 2017) The design of the security error flow
- (03 Oct 2017) The indexing threads
- (02 Oct 2017) Indexing related data
- (29 Sep 2017) Map/reduce
- (22 Sep 2017) Field compression
Comments
This looks great and a lot easier to deal with than managing RavenFS as well.
Quick question - in the screen shot of the above there is a 'Clone' function for the document. I have tried this out in the alpha build but it does not clone the attachment. Is it possible that 'Clone' (maybe optionally?), can also clone the attachments.
An example would be we have a Quote RavenDB document with attached supplier quotes. The user wants to clone the quote without losing the links to the attachments. It prevents us having to manage the cloning of attributes outside of the db, which also means we have to duplicate the physical files by downloading them and the reuploading them into the database I guess?
Ian, Yes, Clone in the beta will clone attachments as well. Versioning will also work on attachments, and will version those as well.
Oren , will we still have RavenFS and file store sessions in RavenDB 4 ?
Ian, No, we have removed those. See the reasoning in the previous post
Hmmm... Ok . I like RavenFS we have actually just written Virtual File System over the top of it to support our Multi-Tenant Application. It's features are great for us.
A typical Tenancy/Application is 400~ files / 60MB. Would you recommend that we turn this into a single document with 400~ Attachments in RavenDB 4? Will it perform / handle that well?
Excellent (re: cloning)... I can see the clone feature is currently using an auto-generated ID. Will there be a way to use the HiLo numbering to avoid this:
Quotes/55 Quotes/56 Quotes/f3984bcf-e7a2-49d6-b196-97e66c336f40 (a clone) Quotes/57
I can see the ability to use sequential numbers exists by adding a "/".
What the storage mechanism for this? Is it JSON inside the document store? What are, if any, the limitations of attachments compared to RavenFS?
Ian, Yes, that should work for this. There is a list of all the attachments per document, so if you have a LOT (400 isn't a lot) then you'll split them to different docs, but that is about it.
Ian, Yes, we'll be using "Quotes/" there in the next release.
Philippe, Attachments are stored in binary format, and there aren't any hard limitations. We aren't doing differential replication, we send the full data, but that turned out to be a feature very few people used.
Nitpicker alert! ;-) I've spotted a bug in your sample. User 123 will change his/her profile picture many, many, many times and nobody else can change theirs..
Remco,
I'm not following, why would that be the case?
The attachment names are scoped to the document in question, so two documents can have different attachments with the same name without issue.
Oren, Remco means in the example you're not using the "userId" parameter to the function, you're always passing "users/123" ;)
Mircea / Remco, Oh, I see it now, thanks!
Is that available? I have 4 alpha 40013 and I don't have a StoreAttachment method. Only GetAttachment...
CheloXL, No, in 4.0 alpha it is available as PutAttachment,IIRC, and as a separate command not on the session. This will be in the beat, which is scheduled for release shortly.
Comment preview