This is an interesting idea, thanks for sharing it. We use multiple databases in our Rails app at Root using https://github.com/ankane/multiverse
Having the database.yml inside the engine directory itself might be problematic. For us at Root, that'd work well since all of our engines are inside our project. How would this work for engines loaded via gems? It'd be hard for somebody to include an engine in their app via a gem and then modify the database.yml. I wonder if it'd be better to have the top-level config/database.yml define the credentials for the engine database somehow. An engine-owned file could be built to use environment variables, but we've also defined other database connection parameters in the yaml file, like disabling prepared statements and setting statement timeouts and the connection pool size. Figuring out how to manage the connections should be solvable. After that though, Rails will still need to solve all of the migration issues mentioned in the @eileencodes RailsConf keynote. From my perspective, that's the bigger challenge. Rails' current approach to migrations assumes one database, and that's why gems like multiverse are necessary to use multiple. Using establish_connection is pretty elegant, but the migrations code is too tightly coupled to one database connection set on ActiveRecord::Base. From my perspective it'd be nice to resolve that first. Ideally, all of the migration code should be able to work by passing in a database connection, rather than needing to modify the global state set on ActiveRecord::Base. Dan On Sunday, May 27, 2018 at 9:43:18 PM UTC-4, Kelly Stannard wrote: > > Hello, > > *Summary* > > After watching the @eileencodes RailsConf keynote, I decided to resurrect > an idea that Rails engines were the key to easy Rails scaling in larger > companies since it promotes separation while being easier than SOA. Part of > that separation is the need to have engines that can connect to their own > database, promoting the portability of the engine. > > Dan Manges articulates the gist of the engines only idea pretty well. > <https://medium.com/@dan_manges/the-modular-monolith-rails-architecture-fb1023826fc4> > This is my original, functioning project from 2 years ago. > <https://github.com/kwstannard/engine_only_app_test> > Current progress towards this goal. > <https://github.com/rails/rails/compare/master...kwstannard:separate_db_engine> > > > *Details of how an engine will work* > Start with a separate, but otherwise normal, database.yml stored in the > engine. The engine's namespaced ApplicationRecord will establish a > connection using that database.yml. Table prefix is also dropped since it > is in its own database. > > I think there is probably a better, less verbose way to have runtime stuff > happen, but just haven't figured it out yet. > > In addition, we should expose new rake tasks, something like this from my > original project > <https://github.com/kwstannard/engine_only_app_test/blob/master/engine_only_helpers/lib/tasks/engine_only_helpers/db.rake> > . > > *Details of how the plugin generator will work* > > Right now I just added a `separate_database` flag so the full command > would be: > > be rails plugin --full --mountable --separate_database bar_service > > Thanks for your time, > > Kelly Wolf Stannard > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at https://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
