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
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.
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.
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.
For a new project my company is considering using Amazon SimpleDB to simplify data storage. The app is a simplistic web dashboard that will be created using Ruby on Rails. What I'm wondering, though, is if I can still use associations like has_many and belongs_to while using SimpleDB as the backend.
For instance, the application has users who log in and have messages. In "normal" Rails with MySQL I could easily do this with the built-in associations. Will using SimpleDB as the storage engine prevent me from doing this? Also, will I have to re-implement the login functionality? I was initially going to use the restful_authentication plugin, but I have no idea if I will have to rewrite it to work with SimpleDB.
I think SimpleDB will be a problem for your wishes....
(and i tink you have to reimplement the login authentication as well, because its based on ActiveRecord like all the other models)..
You should check out SimpleRecord, just like ActiveRecord, but using SimpleDB for backend.
There's a great answer for my question over here Rails shared sessions with activerecord but it has to do with rails 2.2.2. The method used has been deprecated in 2.3.2.
Does anyone know how to use an external database for session data in rails 2.3.2? The overall goal is session sharing between two apps using two different databases. thanks!
Alright, found what I need. Not tested 100% to make sure it's working, but it doesn't spawn errors anymore.
CGI::Session::ActiveRecordStore has been replaced in rails 2.3.2 with ActiveRecord::SessionStore
So the new method to connect to an external db SHOULD be ActiveRecord::SessionStore::Session.establish_connection(:connection_name)