I understand your opinion but i'm not introducing, and not inventing nothing new. Plus Sequel is active record (the pattern not the library).. just try with mongoid or mongomapper..
Rails will get more orm agnostic because you will have the ability to switch between orms that already support that interface.. Ruby on Rails will never be really orm agnostic untill we need to write 2 separate gem, one for active_record (with gererators) and one for mongoid (with fields expressed in models), for any model related feauture. Can you agree now? Migrations are meaningless outside active record (again the pattern not the gem).. we can't enforce a migration centered approach in an ORM agnostic environment.. perhaps to me it seems that is more comfortable to make ActiveRecord to support properties inside models that to ask Mongoid and other 500 ORMs around to dump fields and support migrations. To be even more clear on what ORM-agnostic means: try to ship a Gem for both Mongoid and ActiveRecord without have somewhere in your code an 'if is Activerecord do ... else if do ...' Now if you don't like this approach.. again.. there is no need for this to be mandatory.. an ORM agnostic model implementation needs only to support it, just in case a Gem would require. Considering that ActiveRecord is the most supported ORM by community, without this we never.. and i repeat *never* will really see the benefit of ORM-agnostic models. Gem developers will have to write the same code twice forever or ship it with proprietary adapters in place of the level of abstraction that is missing here. See Devise, as an example, that has dropped schema generation to non migration based ORMs, or Carrierwave that has adapters as external gems. 2012/5/9 Rodrigo Rosenfeld Rosas <[email protected]>: > 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. > -- 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.
