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) > > 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] > (mailto:[email protected]). > To unsubscribe from this group, send email to > [email protected] > (mailto:[email protected]). > 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 [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.
