Em 09-05-2012 12:06, Maurizio Casimirri escreveu:
Yes, i'm sorry .. examples.. anyway: declaring fields in models should not be mandatory! To keep track of renaming, changing and deleting of columns is already up to the migration system. We could think to a rake task to check if everything is up-to-date.. (few line of code) but i don't care too much of it because i think such kind of changes are something that is better to do by hand.The generative approach is something that is needed only for the non-destructive changes (adding column, tables and indexes) IMO. Also you should see the generator for what it is: just something that can write for you something that you should write by yourself otherwise. But here is an example of what misses the migration-alone approach: # paperclip_schema gem: module PaperclipSchema extend ActiveSupport::Concern module ClassMethods def has_attached(name, options = {}) has_attached_file(name, options) field :"#{name}_file_name" field :"#{name}_content_type" field :"#{name}_file_size", :as => :integer field :"#{name}_updated_at", :as => :datetime end end end ActiveRecord::Base.send :include, PaperclipSchema # ~ Application models: class Picture has_attached("image") end class User has_attached("avatar") end now generate migrations, and enjoy using Paperclip (again this is just an very simple example)..
I really don't like this approach. As I've said before, I don't like the idea of mixing database evolution code with the application code itself. And I don't think there is a need for that.
Traditionally, gems like Devise and similar ones will add generators to your application to create the missing columns in the affected models so that you have the chance to review and understand what columns are expected to exist in each model table.
And I don't see any problem with that approach. I don't really think we should try to make migrations a bit easier by providing some annotations to the model classes.
Application Logic is not aware of what happens below and it seems correct to me. How can't you see this is a level of abstraction we don't have now?
I can see it as a level abstraction we don't currently have. I just don't find it useful enough to worth it.
As a counterevidence: how much time will you need to port your code to another ORM.. such as DataMapper.. or switch from DM to ActiveRecord, or even MongoId (supposing you wish also to change database)? This way they would be almost interchangeable.
I've replaced recently my models from ActiveRecord to Sequel and didn't experience any issues during this transition. And my migrations weren't affected at all.
Rails is trying to move to an ORM agnostic model or em i missing something? Well this is a way to make ActiveRecord play nice in the ORM agnostic world.
Why do you think Rails would be more ORM agnostic than it already is just because you're introducing annotations to model classes?
I am already able to use Sequel with Rails and I'm not even using some sequel-rails gem for doing that. So I guess Rails is already ORM agnostic enough in my opinion.
Best, Rodrigo. -- 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.
