Feature Preview: Attachments for Objects

Next week we’ll publish our 1.3 release and it is time for a sneak preview of the new file attachment feature on object level.

File attachments can be uploaded on object level in a little box…

…and were shown in our new menubar on object level:

All files were stored in the DATAGERRY MongoDB database, so no new dependencies are required to use that feature. At a later time (planned for the 1.4 release), we will also provide a file manager, where object attachments and other files can be managed.

Hope, you will enjoy our new feature and as always, you are welcome to share your thoughts about it.

I think it will be a good feature.
The only thing is missing the add object button in this new toolbar
which is now on the right side of the object preview. :slight_smile:
but it is i think only small oversight :slight_smile:
I wonder in that moment menu from right side will disappear and will be on the top and external links will be only shown when clicked in the expand button?
That top menu will be always on top and even when you scroll down with the scroll, it will be visible on the top? or will it disappear as it goes down the page?

I have one more little comment
For my side i think best store for file are directories and only identificators should be store on database.
Database will suffer if files are kept there and the database can grow a lot if there are a lot of files placed ther.
if the files were located on the server, it is always easy to copy and manipulate them, add more resources for them, etc.

i have one question.
Do you think and would be able to create a preview of already saved files to the functionality of adding files?

Hi @marcinw,

the idea of storing that files in MongoDB was to minimize dependencies, especially for cloud (Docker) environments, where we don’t want to store data files in directories. An alternative would be an S3 like storage service, which we need to provide like MongoDB and RabbitMQ.

File attachments for objects was meant to be an add-on for DATAGERRY that should not have too much functionality. Of course, a preview of files or version control, or other functionality would be possible, but we don’t want to provide a replacement for a document management tool, we want to keep it simple and small.

Hello, just wanted to share my thoughts on this matter:

I personally like the idea of keeping it simple and small: a lot can already be resolved with links (to a CDN or CMS). When the document changes, the link should also change (to bubble the change event to the CMDB).

Further on the suggestions:

  • One advantage of handling blob storage in the CMDB, is that you can apply/inherit access control. This way it fits nicely into the current framework, which significantly shortens the path to a release. Although, I’m also not really a fan of storing blobs in MongoDB. It does have GridFS to do away with the 16MB limit (which is probably not even an issue for CMDB attachments), but in the end they are still BSON documents in MongoDB and the chain from request to response will have some overhead because of it. We could run a seeder with what’s considered ‘a lot of images’ and see how it impacts on resources & performance.
  • Storing the files in the FS is manageable in containerized environments (volumes) and they may present a way to manage the files externally. The disadvantage is that this is a vulnerable interface, and delete/change events can only bubble to the CMDB if you add a service that watches the directory.