This is interesting. I don't like AR but I like AR migrations :)
So I disabled AR in my Rails project and I'm using Sequel instead. But
I'm using AR migrations to evolve the database scheme. For that I use
this great project:
https://github.com/thuss/standalone-migrations
Maybe this could help you with your migrations issues.
Best,
Rodrigo.
Em 15-10-2012 14:57, ChuckE escreveu:
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 <[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
<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
<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.
--
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.
