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) > > 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 > https://github.com/rafaelfranca > > > > On Mon, Oct 15, 2012 at 1:04 PM, ChuckE <[email protected]<javascript:> > > 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. >> To post to this group, send email to >> [email protected]<javascript:> >> . >> To unsubscribe from this group, send email to >> [email protected] <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/-/6pbcU1t9q6UJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
