Hey Jwo, Sorry, I didn't express myself correctly, I guess. In Sinatra, for one to be able to run/create migrations, one has to install an extension to the AR gem in order for one to access a small subset of the known Rails db tasks.
On Monday, October 15, 2012 10:27:13 PM UTC+2, JWo 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) > > 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]> 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]. > 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. > > > -- > 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]<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/-/RlSBMbBp7EEJ. 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.
