Are there any plans to move the schema definition from migrations to the model, where it should be? Like og does, which I think is used by the ruby Nitro framework... ObjectGraph: http://www.rubygarden.org/index.cgi/Libraries/og_t... Example code: [code] class Post property :title, String, :sql => 'VARCHAR2(32) NOT NULL' property :body, String property :author, String property :create_time, Time property :hits, Fixnum, :sql_index => true has_many :comments, Comment end [/code]
on 2006-01-16 11:45
on 2006-01-16 12:30
Peter P. wrote: > Are there any plans to move the schema definition from migrations to the > model, where it should be? > says who??? dont hold your breath...I dont think that would happen...
on 2006-01-16 14:47
2006/1/16, Peter P. <email@example.com>: > Are there any plans to move the schema definition from migrations to the > model, where it should be? The schema definition is in the application's database, no need to use migrations to have a schema. Douglas
on 2006-01-16 18:04
I like the control over the database layout with the ":sql" extension to further refine data types. If the SQL to create the database objects could also be generated to run through psql or sqlplus, that would be a bonus. Including alter statements to handle migrations, and changes to the datbase. Would also be nice to have to indicate what tablespace, storage parameters, etc that a table or index would be created in. This would be specific to Oracle or PostgreSQL. Any reason the extensions couldn't just be passed to the SQL generator which creates the database objects in the first place? I think taking some of the pieces from OG would be nice, and having all the metadata in the class definition is a bonus. Cheers, Mike -- Mobile: +81-80-3202-2599 Office: +81-3-3395-6055 "You can figure out how to get it off. It's on the Internet. I looked it up." Martha Stewart - re: her proximity restraint.
on 2006-01-16 19:19
I'd love to see the option of a "domain-first" ORM like Og in rails... but I wouldn't wait for the committers to agree with you. Throw a project together, make an announcement on the list and see if you can get enough people to help. Maybe the Og devs would be interested. For that matter, I'm still very new to rails, but I wonder if it would be that much work to get ActionPack talking to Og? Shouldn't be, since the controllers and views are clients of the model. The main chunk of work would probably be writing new generators. You would write up the definitions for your model classes and then have the generators create controllers and views. Talking to the db is all Og. It would also be nice if, with a single configuration, you could have Og write to flat files, yaml, or xml. I haven't looked too closely at Og, so maybe it already does that... I've seen others talking about this idea. Someone just needs to stop talking about it and start doing it. If we're still just talking about it in a few months (after I've had a chance to learn a bit more about Ruby and Rails), I'll do it. Hopefully someone will beat me to it. :-) b
on 2006-01-16 19:34
there is no problems using another ORM package in a rails project... Ben M. wrote: > For that matter, I'm still very new to rails, but I wonder if it would > be that much work > to get ActionPack talking to Og? Shouldn't be, since the controllers and > views are clients > of the model. The main chunk of work would probably be writing new > generators. You would > write up the definitions for your model classes and then have the > generators create > controllers and views. Talking to the db is all Og.
on 2006-01-16 20:05
mikkel wrote: > there is no problems using another ORM package in a rails project... > What other ORMs have you used? James -- http://www.ruby-doc.org - Ruby Help & Documentation http://www.artima.com/rubycs/ - The Journal By & For Rubyists http://www.rubystuff.com - The Ruby Store for Ruby Stuff http://www.jamesbritt.com - Playing with Better Toys http://www.30secondrule.com - Building Better Tools
on 2006-01-16 20:44
James B. wrote: > Yeah... and I don't know if you could really call it a "rails" app at that point... ActiveRecord is so central to rails... b
on 2006-01-17 14:13
Well the model describes the data so it seems natural to me to have the schema definition in the model. Of course this is my opinion.. Having the schema in the model also allows instant visualisation of what fields that model/table has. I really liked Migrations when I first used it - its great for team collab as well - but I think the schema should be in the model. The trouble with og is you cant rollback like with Migrations, unless... you use version control you could rollback the model.rb file and get the old schema if required. The model represents the data. The model could create the table (automatic setup program for install of an application a bonus), plus I think it is more Object Orinentated to do this. Self contained classes of independant functionality. The model should not have to be dependant on a exisitng table, it should be able to create its own - but i guess thats nit picking. Just some thoughts, I think I will try og instead of ActiveRecord, you would surly still call it a Rails app... As long as dispaches is being used I guess its a rails app :) Peter P..
on 2006-01-18 04:25
2006/1/17, Peter P. <firstname.lastname@example.org>: > The model should not have to be dependant > on a exisitng table, it should be able to create its own - but i guess > thats nit picking. > If there is already a table, but it has a diffferent schema from the model... you want the model to simply drop the the old table?? Douglas
on 2006-01-18 05:46
> > The model should not have to be dependent > > on a existing table, it should be able to create its own - but i guess > > thats nit picking. > > If there is already a table, but it has a different schema from the > model... you want the model to simply drop the the old table?? This is the crux of the problem. Schema-in-model sounds nice until the first time you have to change it in an application where you care about the data. Suddenly schema-in-model is liability. One that forces you to get wet and most often manage the entire migration without the help of the framework. I summarized all the reasons for why schema-in-model is unattractive to developers that care about keeping their schema as agile as their code and have real data to worry about in http://media.rubyonrails.org/video/migrations.mov. Re different model backends: I've had Rails applications that used both Madeleine and flat files. Others have interfaced with ActiveLDAP. Active Record is not a necessity for a Rails application. But yes, if you need a relational backend, it works better than the alternatives because we based the conventions around it. So smooth, yes, necessary, no. -- David Heinemeier H. http://www.loudthinking.com -- Broadcasting Brain http://www.basecamphq.com -- Online project management http://www.backpackit.com -- Personal information manager http://www.rubyonrails.com -- Web-application framework
on 2006-01-18 13:34
Douglas L. wrote: > 2006/1/17, Peter P. <email@example.com>: >> The model should not have to be dependant >> on a exisitng table, it should be able to create its own - but i guess >> thats nit picking. >> > > If there is already a table, but it has a diffferent schema from the > model... you want the model to simply drop the the old table?? > > Douglas Yes I see the point... but there would be no need to drop the table, only change what is different, just as migrations would. It partly depends on if you are talking about development or production, and if production I guess retaining exisitng data is important, and to do this yes you get better flexability in migrations because you can add migration code. Og I guess has static schema, not transisional. I think my point partly comes from retaining pure OO programming... the model is the data, all encompassing. But I think none comprise is more practical? Pete.