Hi, I was asking before if people use the ActiveRecord create table method to ensure portable table definitions. Seems like no one does it that way. I wonder why and also if people are so interested in database abstraction then how do they avoid writing raw SQL. Thanks, Peter _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Peter Michaux wrote:> Hi, > > I was asking before if people use the ActiveRecord create table method > to ensure portable table definitions. Seems like no one does it that > way. I wonder why and also if people are so interested in database > abstraction then how do they avoid writing raw SQL.I can only answer for myself, but AR migrations are perfectly good enough for me, as long as I don''t feel the need to pull in from ODBC or write to SQLite. But those are just constraints of the environment I''m in, and pretty variable at that. -- Alex
Peter Michaux wrote: > Hi, > > I was asking before if people use the ActiveRecord create table method > to ensure portable table definitions. Seems like no one does it that > way. I wonder why and also if people are so interested in database > abstraction then how do they avoid writing raw SQL. We''re working on a project with about 40 tables (about 10 of them join tables). We started in a spreadsheet, then moved to a sql file full of creates and permission settings, and now modify and keep that file up to date as we work. Most things we do (CRUD) is abstracted, but some things have to be semi-raw or raw. The Rails book (agile dev with Rails) seems to assume you would start with SQL definitions. It seems easier that way to get permissions, defaults, etc. set up. I''m not sure if using AR would make things any easier (for us anyway) and I don''t know if it we could have been able to set permissions and other attributes as easily. Phil