Hey Ryan, - I'm not working with multiple databases on one application, I'm working with multiple applications (using different ruby frameworks, but all using ActiveRecord) on one database. Actually I've worked already with one Rails application on multiple databases, and with some configuration over convention, it is possible. - The migration tasks don't come with Rails, they come with ActiveRecord. Rafael said that the rake tasks are only made available via Railtie, hence they are only automagically usable in a Rails environment. But they belong to ActiveRecord. My concern is only that these AR tasks make use of Rails (and Engine, in this case) variables to make assumptions about migrations directory and such, instead of making it part of the ActiveRecord configuration.
On Monday, October 15, 2012 11:36:58 PM UTC+2, Ryan Bigg wrote: > > I think the answer here that Rafael gave is spot-on. The migration tasks > that come with Rails are designed with one database in mind. If you're > operating with multiple databases, then you should create your own > migration tasks that migrate your databases for you. > > On 16 October 2012 07:27, Jesse Wolgamott > <je...@comalproductions.com<javascript:> > > wrote: > >> Installing extensions is not a requirement to get ActiveRecord migrations >> to work. It might help, but the code required to migrate is pretty straight >> forward. Rails makes a lot of assumptions about what you want to do with >> your databases, with different environments (dev/test/etc), seeding, or >> that you might have migrations in engines that you could run. >> >> I created a simple repo that uses AR without Rails: >> https://github.com/jwo/ActiveRecord-Without-Rails (postgres specific >> setup). And if you don't need to migrate, you can simply connect to an >> existing database: https://github.com/jwo/dbfu … Setup for these ruby >> only projects is minimal. You don't automagically get all the rake tasks >> that Rails gives you, but in simple ruby projects you might not need them. >> >> - jwo >> >> >> On Monday, October 15, 2012 at 12:57 PM, ChuckE wrote: >> >> But that's the point: I think the rake tasks shouldn't be >> Rails-dependent. Since ActiveRecord is dependent from the migration it must >> run before it is deemed loadable, I think the ORM as an independent ORM >> should take that into consideration, and make it configurable from the >> railtie, but not in the databases rake task itself. The migrations are a >> fundamental part of AR integration, and its rake tasks as well. I mean, >> when I need to install an extension to run a small subset of migrations for >> the Sinatra framework, it clearly shows that something could be done a >> little bit differently in that respect. The rake tasks should be dependent >> of rake, not Rails (unless there is a very good reason for it, but I don't >> see which in this particular example. You know the framework better, maybe >> you can tell me of an use case where it does make sense). >> >> One question regarding railtie: Can one define in the app configuration >> more than one migration path, the same way we can do for >> models/helpers/etc? It would at least mitigate my problems on the Rails >> side, even though I still think a full AR solution would be best. >> >> Cumprimentos >> >> On Monday, October 15, 2012 6:22:26 PM UTC+2, Rafael Mendonça França >> wrote: >> >> Active Record in its own box. The problem is that you want to use >> something specific to Rail, the database taks. >> >> As you can see in the [filename of the database task](https://github.com/ >> **rails/rails/blob/3-2-stable/**activerecord/lib/active_** >> record/railties/databases.rake<https://github.com/rails/rails/blob/3-2-stable/activerecord/lib/active_record/railties/databases.rake> >> **) it should be only loaded when you are using rails and this is why it >> is inside the railties folder. >> >> You can use migrations without use these tasks, but you will have to make >> your own task. This is a fair cost to those that don't want to use the >> railties infrastructure. >> >> Rafael Mendonça França >> http://twitter.com/**rafaelfranca <http://twitter.com/rafaelfranca> >> https://github.com/**rafaelfranca <https://github.com/rafaelfranca> >> >> >> >> On Mon, Oct 15, 2012 at 1:04 PM, ChuckE <honeyry...@gmail.com> wrote: >> >> Hi, >> >> I found a special ActiveRecord case which messes a bit one requirement. I >> have two applications sharing the same DB. For this reason we found wise to >> share the DB mapping logic among both applications, namely, our >> activerecord models. After extracting them into a gem and bundling them >> into the two applications, everything went well. >> >> Now, we found out it would also be wise to share the migrations, schema, >> config, etc., maybe "delegate" such rake tasks as create migration and >> schema dump to that shared repo, which would contain also this part of the >> logic. Thing is, the use of the Rails class throughout all the rake tasks >> concerning migrations make that impossible. Specially the load_config rake >> task, which is apparently run before each and every rake task. This one >> basically overwrites any rewrite I might have had done on the >> ActiveRecord::Migrator.**migration_paths with the local 'db/migrate' >> folder. Which in my case would be empty in both application trees and full >> on the shared repo. Because of that, I can't wisely set a new migration >> path without entering a world of hurt and non-stop monkey patch. Which I'll >> avoid by now. But basically, that load_config rake_task is messing up my >> plans. >> >> Another concern is the use of the Rails class itself. It could be the >> case that I would be talking about two rails applications, but one of them >> happens to be Sinatra, which doesn't own (or shouldn't own) any Rails >> class. I've seen how they extended the migrations part for their version of >> active record. Also a very limiting solution. So, I guess the solution will >> probably not come from the frameworks readapting their needs to >> activerecord, but activerecord having a consistent solution in its box, >> making it then more extendable for other frameworks (I don't know how Merb >> handles this, I might investigate into that). >> >> So, I'd like to open the debate on the subject. Or maybe it has been >> opened previously. I'd much like to hear your opinion. >> >> Regards, >> Tiago >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ruby on Rails: Core" group. >> To view this discussion on the web visit https://groups.google.com/d/** >> msg/rubyonrails-core/-/**o5xL8FsQqZsJ<https://groups.google.com/d/msg/rubyonrails-core/-/o5xL8FsQqZsJ> >> . >> To post to this group, send email to rubyonra...@googlegroups.**com. >> To unsubscribe from this group, send email to rubyonrails-co...@** >> googlegroups.com. >> For more options, visit this group at http://groups.google.com/** >> group/rubyonrails-core?hl=en<http://groups.google.com/group/rubyonrails-core?hl=en> >> . >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ruby on Rails: Core" group. >> To view this discussion on the web visit >> https://groups.google.com/d/msg/rubyonrails-core/-/6pbcU1t9q6UJ. >> To post to this group, send email to >> rubyonra...@googlegroups.com<javascript:> >> . >> To unsubscribe from this group, send email to >> rubyonrails-co...@googlegroups.com <javascript:>. >> For more options, visit this group at >> http://groups.google.com/group/rubyonrails-core?hl=en. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ruby on Rails: Core" group. >> To post to this group, send email to >> rubyonra...@googlegroups.com<javascript:> >> . >> To unsubscribe from this group, send email to >> rubyonrails-co...@googlegroups.com <javascript:>. >> For more options, visit this group at >> http://groups.google.com/group/rubyonrails-core?hl=en. >> > > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-core/-/V2lIs8I1KfMJ. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
