I wanted to replace Carrierwave with ActiveStorage in a Rails 6 app that uses Mongoid as storage (and carrierwave-mongoid) but looks like this storage needs an existing Active Record setup. The rails active_storage:install tasks fails. I tried a mongo AR gem adapter with no luck. Is it possible to workaround it? AFAICS it needs to create 2 new tables with some attachments metadata.
Mongoid does not include any code that is related to ActiveStorage.
Assuming ActiveStorage requires a storage backend (like ActiveRecord), and furthermore if ActiveStorage assumes the application it is in uses ActiveRecord (which isn't the case for applications using Mongoid), you would need to investigate what exactly is required for AS+Mongoid integration and perform that work.
See also https://jira.mongodb.org/browse/MONGOID-4623 where this was requested.
Related
I am starting an blog with mongoid and I would like to use trix editor along with all facilities of action_text. Is it possible?
Mongoid cannot be used with ActionText due to its reliance on ActiveStorage, which does not support Mongoid (see https://github.com/rails/rails/issues/31408).
Requests have been made to remove the dependency on ActiveRecord from ActiveStorage (https://github.com/rails/rails/issues/42901) however this is not something Rails core is looking to do.
There is a case we want to use the Active Storage without Rails. We are using activemodel, activejob in Gemfile. we would like to use activestorage in our ruby application.
Is it possible to configure and use activestorage without rails? if so can anyone please give us the suggestion how to configure and use.
Thanks in advance!
Background
We have a legacy, monolith Rails 4.2 project. Call it "Classic."
"Classic" uses Paperclip for dealing with the storage of assets (photos, attachements, etc.) in a 3rd-party system.
We are now breaking the monolith into multiple Rails 6 micro-services. Call it "New".
"Classic" and "New" share the same DB.
The Goal
We want to stop using Paperclip because it is now deprecated and instead use ActiveStorage.
The Problem
"Classic" and "New" are going to have to live at the same time for a while.
"New" cannot use Paperclip because it's deprecated.
"Classic" cannot use ActiveStorage because it requires at least Rails 5.2. ("Classic" cannot realistically be uplifted to 5.2)
So we're stuck in a situation where "New" can use the newer technology, but it requires a DB change that "Classic" will not be compatible with and they share the same DB and "Classic" cannot use the newer technology.
The Question
Has anyone else ever had to deal with a situation like this and was able to find an approach that worked? Or maybe someone has another idea?
My (potentially bad) Idea
Maybe we could go ahead and implement everything in "New" to use ActiveStorage. We could provide some RESTful endpoints that would allow for the retrieval/create/update/destroy of 3rd-party hosted assets.
Then in "Classic", anywhere that Paperclip is used, we could just replace that logic and have it make RESTful calls out to our new endpoints in "New". Along with that, we'd also have to devise a strategy for identifying every asset that was managed via Paperclip and then create equivalent records over in the new ActiveStorage schema. That way the logic in "New" would be able to access past assets. I'm not sure if that is a realistic approach and it probably has some serious shortcomings that I'm overlooking, but it was a thought.
Using this Paperclip to ActiveStorage Migration doc as a guide, I was able to workout a successful solution.
Here is what I did.
In New I built the migration to add the 2 ActiveStorage tables.
Ran the migration.
Tweaked the ConvertToActiveStorage class (provided in the linked migration doc), to iterate over my "Paperclipized" items and in-turn create equivalent ActiveStorage records. Note :: Rather than run the ConvertToActiveStorage as a migration, I set it up to be ran as a Rake task.
Executed the ConvertToActiveStorage logic in Classic.
Updated the models in New to begin working with ActiveStorage objects (rather than the old "Paperclipized" objects). Basically changed from something like :: has_one :photo, dependent: :destroy to has_one_attached :photo
In Classic, added after_create, after_update and after_destroy callbacks on the Paperclipized models. Those callbacks are responsible for creating/updating/destroying the equivalent ActiveStorage records. This allows for Classic ('Paperclipized') and New ('ActiveStorage structure') to exist for a while longer at the same time. So when someone goes into Classic and adds a new user image, the callback will handle also going and creating the equivalent ActiveStorage records so that New will be able to interact with the user image. Same idea for the update and delete. Eventually, when New has the ability to create/update/destroy images, then I'll need to provide callbacks to go the other way (ActiveStorage to Paperclip) but that's a battle for a future day.
Is it possible to add ActiveStorage on rails 6 without adding ActiveRecord
I am using API application having only mongoDB database. Now, as I have observed that FSGrid which actually a good option, having a database size issue and we want physical file available on S3.
Sadly, it's still not possible now in April 2020.
From Mongodb Docs:
At this time ActiveStorage requires ActiveRecord and is not usable with Mongoid.
They are not working on it and suggest people to try to implement it with the current API as discussed here
Is it possible to use multiple couchdb databases for data in rails app while using the CouchRest Model gem? Right now in my rails app I specify the one couchDB database in config/couchdb.yml. I was wondering if it possible to have more than one couchdb databases being used by one rails app?
You might want to check out this answer - it worked for my case where I wanted a database for each user
Recommended use of couchrest model in a multi-tenant app