Hi, all. With unbelievable difficulty, I have the mysql gem installed without warnings with the following components: OSX Leopard 10.6.2 ruby 1.8.7 (2008-08-11 patchlevel 72) [universal-darwin10.0] Rails 2.3.5 mysql (2.8.1) [gem version] MySQL Server 5.1.44 I even rebuilt my whole project a few minutes ago, thinking an unsuccessful previous install might have failed to generate my database. Yet when I run rake db:migrate, I get the following errors: iMacMike:pfmpe mikemontagne$ rake db:migrate --trace (in /Users/mikemontagne/rproj/pfmpe) ** Invoke db:migrate (first_time) ** Invoke environment (first_time) ** Execute environment ** Execute db:migrate rake aborted! Unknown database ''pfmpe_development'' /Library/Ruby/Gems/1.8/gems/activerecord-2.3.5/lib/active_record/connection_adapters/mysql_adapter.rb:589:in `real_connect'' /Library/Ruby/Gems/1.8/gems/activerecord-2.3.5/lib/active_record/connection_adapters/mysql_adapter.rb:589:in `connect'' /Library/Ruby/Gems/1.8/gems/activerecord-2.3.5/lib/active_record/connection_adapters/mysql_adapter.rb:203:in `initialize'' /Library/Ruby/Gems/1.8/gems/activerecord-2.3.5/lib/active_record/connection_adapters/mysql_adapter.rb:75:in `new'' /Library/Ruby/Gems/1.8/gems/activerecord-2.3.5/lib/active_record/connection_adapters/mysql_adapter.rb:75:in `mysql_connection'' /Library/Ruby/Gems/1.8/gems/activerecord-2.3.5/lib/active_record/connection_adapters/abstract/connection_pool.rb:223:in `send'' /Library/Ruby/Gems/1.8/gems/activerecord-2.3.5/lib/active_record/connection_adapters/abstract/connection_pool.rb:223:in `new_connection'' /Library/Ruby/Gems/1.8/gems/activerecord-2.3.5/lib/active_record/connection_adapters/abstract/connection_pool.rb:245:in `checkout_new_connection'' /Library/Ruby/Gems/1.8/gems/activerecord-2.3.5/lib/active_record/connection_adapters/abstract/connection_pool.rb:188:in `checkout'' /Library/Ruby/Gems/1.8/gems/activerecord-2.3.5/lib/active_record/connection_adapters/abstract/connection_pool.rb:184:in `loop'' /Library/Ruby/Gems/1.8/gems/activerecord-2.3.5/lib/active_record/connection_adapters/abstract/connection_pool.rb:184:in `checkout'' /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'' /Library/Ruby/Gems/1.8/gems/activerecord-2.3.5/lib/active_record/connection_adapters/abstract/connection_pool.rb:183:in `checkout'' /Library/Ruby/Gems/1.8/gems/activerecord-2.3.5/lib/active_record/connection_adapters/abstract/connection_pool.rb:98:in `connection'' /Library/Ruby/Gems/1.8/gems/activerecord-2.3.5/lib/active_record/connection_adapters/abstract/connection_pool.rb:326:in `retrieve_connection'' /Library/Ruby/Gems/1.8/gems/activerecord-2.3.5/lib/active_record/connection_adapters/abstract/connection_specification.rb:123:in `retrieve_connection'' /Library/Ruby/Gems/1.8/gems/activerecord-2.3.5/lib/active_record/connection_adapters/abstract/connection_specification.rb:115:in `connection'' /Library/Ruby/Gems/1.8/gems/activerecord-2.3.5/lib/active_record/migration.rb:435:in `initialize'' /Library/Ruby/Gems/1.8/gems/activerecord-2.3.5/lib/active_record/migration.rb:400:in `new'' /Library/Ruby/Gems/1.8/gems/activerecord-2.3.5/lib/active_record/migration.rb:400:in `up'' /Library/Ruby/Gems/1.8/gems/activerecord-2.3.5/lib/active_record/migration.rb:383:in `migrate'' /Library/Ruby/Gems/1.8/gems/rails-2.3.5/lib/tasks/databases.rake:116 /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:617:in `call'' /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:617:in `execute'' /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:612:in `each'' /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:612:in `execute'' /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:578:in `invoke_with_call_chain'' /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'' /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:571:in `invoke_with_call_chain'' /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:564:in `invoke'' /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:2019:in `invoke_task'' /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1997:in `top_level'' /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1997:in `each'' /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1997:in `top_level'' /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:2036:in `standard_exception_handling'' /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1991:in `top_level'' /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1970:in `run'' /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:2036:in `standard_exception_handling'' /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1967:in `run'' /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/rake-0.8.3/bin/rake:31 /usr/bin/rake:19:in `load'' /usr/bin/rake:19 ------------------------- Excuse me for posting all of this, but I thought there might be something someone else would catch in this that I didn''t. In any case, yes, MySQL Server is running. I''m using MySQL Workbench 5.2.16 beta for local administration. The root account requires no password: and these are the functional contents of my database.yml: development: adapter: mysql encoding: utf8 reconnect: false database: pfmpe_development pool: 5 username: root password: socket: /tmp/mysql.sock # Warning: The database defined as "test" will be erased and # re-generated from your development database when you run "rake". # Do not set this db to the same as development or production. test: adapter: mysql encoding: utf8 reconnect: false database: pfmpe_test pool: 5 username: root password: socket: /tmp/mysql.sock production: adapter: mysql encoding: utf8 reconnect: false database: pfmpe_production pool: 5 username: root password: socket: /tmp/mysql.sock Does anybody have any idea what I still have fudged up here? Why isn''t the database being created? Are we supposed to manually create our database schema when working with the MySQL gem? Regards, mike -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On Sun, Mar 21, 2010 at 6:25 PM, Mike Montagne <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:> Does anybody have any idea what I still have fudged up here? Why isn''t > the database being created? Are we supposed to manually create our > database schema when working with the MySQL gem?You have to create your databases regardless of what DB you''re using -- as I just pointed out in your previous thread. Are you reading any of the responses? -- Hassan Schroeder ------------------------ hassan.schroeder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org twitter: @hassan -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Sorry for this. It''s my first go-around with RoR/MySQL. Got it: rake db:create RAILS_ENV=''development'' Then: rake db:migrate --trace ---------- Still, if anybody has any general pointers about how to go about developing MySQL locally... much appreciated. Regards, mike -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Hassan Schroeder wrote:> > Are you reading any of the responses? > > -- > Hassan Schroeder ------------------------ hassan.schroeder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org > twitter: @hassan:-) Sorry, Hassan. I didn''t see your response yet. But until I left to here, I read the whole thread. Thanks for the answer, and let me ask you one thing then: What''s the basic procedure for local development and deployment of the tables? Do you suffer the database-agnostic field definitions of the local development environment (db:create and db:migrate); or, wanting to test with real field definitions, to you go ahead and refine your table declarations locally, as you would in what you deploy to the server? Thanks, mike -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On Sun, Mar 21, 2010 at 7:24 PM, Mike Montagne <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:> What''s the basic procedure for local development and deployment of the > tables? Do you suffer the database-agnostic field definitions of the > local development environment (db:create and db:migrate); or, wanting to > test with real field definitions, to you go ahead and refine your table > declarations locally, as you would in what you deploy to the server?I''m not sure what you mean by "real field definitions" -- can you go into a little more detail? What is it you think you can''t do within the scope of migrations? And "deploy to the server" can cover a lot of different scenarios, so you might want to describe what you mean by that, too. -- Hassan Schroeder ------------------------ hassan.schroeder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org twitter: @hassan -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Hassan Schroeder wrote:> On Sun, Mar 21, 2010 at 7:24 PM, Mike Montagne <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> > wrote: > >> What''s the basic procedure for local development and deployment of the >> tables? Do you suffer the database-agnostic field definitions of the >> local development environment (db:create and db:migrate); or, wanting to >> test with real field definitions, to you go ahead and refine your table >> declarations locally, as you would in what you deploy to the server? > > I''m not sure what you mean by "real field definitions" -- can you go > into a little more detail? What is it you think you can''t do within the > scope of migrations? > > And "deploy to the server" can cover a lot of different scenarios, so > you might want to describe what you mean by that, too. > > -- > Hassan Schroeder ------------------------ hassan.schroeder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org > twitter: @hassan1. "Real field definitions": There''s a big difference between scaffolding: script/generate scaffold tablename amendment_id:integer first_name:string middle_name:string last_name:string anonymous_signature:boolean email_address:string email_bounces:integer referrer_email:string referrer_id:integer address1:string address2:string city:string c_code:string state_province_or_territory:string zip_or_postal_code:string comment:string And the usual SQL route to creating a table: CREATE TABLE tablename (id integer NOT NULL AUTO_INCREMENT PRIMARY KEY, ip integer, amendment_id integer, first_name varchar(25), middle_name varchar(25), last_name varchar(30), anonymous_signature tinyint, email_address varchar(100), email_bounces tinyint, referrer_email varchar(100), address1 varchar(100), address2 varchar(100), city varchar(25), c_code varchar(2), state_province_or_territory varchar(2), zip_or_postal_code varchar(10), comment varchar(125), created_at datetime, updated_at datetime) ENGINE = INNODB; In the former, you''re not even passing the information to the environment to build the tables you want. Of course then, it''s critical to convey your intended design to deployment. A varchar(25) (intended field designation) requires 1/10th the disk resources that a string field (which translates to varchar(255)). Migrating the database agnostic definitions of scaffolding then is not producing the intended schema result. 2. Thus the concern about migrating the scaffolding schema''s limited means of defining an intended schema with automated deployment processes, which still lack even the data from which your intended schema could be deduced. You''ve never provided it. So, what I''m asking is, how do you usually handle these issues in RoR? Do you just tolerate the consequences of scaffolding; or do you test and develop on your intended schema; and, if you modify the schema to your intentions with additional tools, is that preserved or destroyed by further migrations? My inclination is to want to revise/refine the resultant schema to my intended table design. I''m also concerned about how RoR deployment might inadvertently affect my schema on a destination server. How do you ensure migrations to a production table don''t affect the intended schema of installed tables? These are regular concerns for anyone with a background in RDBMS, just now getting their feet wet in RoR. Thanks, m -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On Sun, Mar 21, 2010 at 9:43 PM, Mike Montagne <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:> These are regular concerns for anyone with a background in RDBMS, just > now getting their feet wet in RoR.Let it go, at least for a short vacation :-) Do a quick search on "premature optimization". Consider that the whole point of an agile framework like Rails is to facilitate getting features to customers, quickly. Having to optimize your app to handle too-many-page-views is a good problem, but you can deal with it closer to the actual event. -- Hassan Schroeder ------------------------ hassan.schroeder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org twitter: @hassan -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Hassan Schroeder wrote:> On Sun, Mar 21, 2010 at 9:43 PM, Mike Montagne <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> > wrote: > >> These are regular concerns for anyone with a background in RDBMS, just >> now getting their feet wet in RoR. > > Let it go, at least for a short vacation :-) > > Do a quick search on "premature optimization". > > Consider that the whole point of an agile framework like Rails is to > facilitate getting features to customers, quickly. > > Having to optimize your app to handle too-many-page-views is a > good problem, but you can deal with it closer to the actual event. > > -- > Hassan Schroeder ------------------------ hassan.schroeder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org > twitter: @hassanNo sarcasm intended... but I''m not about to buy the idea that "premature optimization" *is* the root of all evil; nor that starting out with obtuse translations of data types which broadly impose a ten fold *overusage* of resources is "agile," when the necessary definitions of the field types are obvious from the start, and "agility" (IMO) would be to broadcast those obvious definitions to every phase of your design -- at least *so that, with great grief, you aren''t forced to revise them later. After the short vacation then, what''s the solution? We sit around at our desks and exalt in the fact we proved a theory of "premature optimization?" No way. If it''s worth doing; it''s worth doing right. We''re not talking about "premature" optimization. We''re talking about starting out with a concept which will get us there with the least stress all the way. That goal isn''t a challenged to be deferred. It''s a fundamental and indispensable building block of *not* making a small job a lifetime job. I''m not saying this just to argue. I don''t care if you dispense with database design right out the gate, even as it''s such a basic issue that any reasonably skilled RDBMS developer can envision that design right out the gate (with little downstream refinement required at least)... and *real agility* would be, to record that prescription in their "agile framework" *once*, from the beginning, so that it''s a job done, *and* they *can* proceed "agilely" from the beginning. Let''s not argue about this; let''s get at the answers -- become truly agile as agile can be. No one betters the path to the end by purposely starting off with a wrong principle, which a) simply multiplies work at least because it has to be straightened out somewhere; and which b) circumvents a whole set (usually a huge one) of facts which as a consequence, are never "tested" under real conditions. The assumption that the latter is "premature optimization" would be a huge contributing factor to what is wrong with software today. How does my "agile" application react to 3-character input to an intended (and obvious) 2-character field, when my "agile" (incoherent?) development environment simply won''t accept (or will it, which was my question) the 2-character field definition -- instead translating it to a whopping 255 characters? (!) The answer to my question should not only be easy... it should be a fundamental skill. You mean nobody cares? A field has to handle 2-character country codes for instance, and every "agile" developer simply lives with 255-character, auto-translated field definitions, to "deal with" that later -- on a living system? No way. I was hoping you were going to tell me that all I have to do is, instead of: def self.up create_table :amendments do |t| t.string :c_code t.string :c_name t.integer :tran_id t.integer :priority t.timestamps end I could replace this with some syntax for executing SQL (which I''m about to look up all the same): def self.up create_table :amendments do |t| t.[execute_sql] :[CREATE TABLE amendments (id integer NOT NULL AUTO_INCREMENT PRIMARY KEY, c_code varchar(2), c_name varchar(35), tran_id integer), priority tinyint, created_at datetime, updated_at datetime) ENGINE = INNODB;] end So this would fit my concept of "agility," because the design is obvious, and because we do this obvious chore once -- eliminating the unnecessary downstream work. My concerns about this still are, does our agile framework want/insist upon creating the timestamps fields (which this SQL Create would produce)? Does the framework itself produce id field also? Do we truncate these fields our SQL statement? Can I just change the template code to such an SQL statement and BE agile? That''s my question. I don''t want to start out, obviously needing to plan for 2-character fields, and suffering whatever downstream ramifications of a "agility" which requires that I alter my table structure to an obvious, intended structure (as opposed to "premature optimization")... with all the resultant, unnecessary difficulties of doing so on a "production" database, *hobbled* by a concept that declaring and working with mere obvious principles is "premature optimization." So let''s not argue about this. I should be able to *start* with my intended design far faster than I can *eventually* modify a wrong design -- imposed in the name of "agility" -- to the right one (which in the least, is twice the work). Regards, mike -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On 22 March 2010 16:08, Mike Montagne <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:> So let''s not argue about this. I should be able to *start* with my > intended design far faster than I can *eventually* modify a wrong design > -- imposed in the name of "agility" -- to the right one (which in the > least, is twice the work).If you don''t like the field definitions generated by the scaffold then you can edit the migration before you run it, or run another migration later. Is there anything in your sql table creation that cannot be specified in migration code? Colin -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On 22 March 2010 04:43, Mike Montagne <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:> In the former, you''re not even passing the information to the > environment to build the tables you want. Of course then, it''s critical > to convey your intended design to deployment. A varchar(25) (intended > field designation) requires 1/10th the disk resources that a string > field (which translates to varchar(255)).In the case of MySql I believe that the length of a varchar only specifies the maximum length, it does not affect the actual space used in the db as the data is stored as variable length records. I don''t know about postgresql. Colin -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Colin Law wrote:> On 22 March 2010 04:43, Mike Montagne <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote: >> In the former, you''re not even passing the information to the >> environment to build the tables you want. Of course then, it''s critical >> to convey your intended design to deployment. A varchar(25) (intended >> field designation) requires 1/10th the disk resources that a string >> field (which translates to varchar(255)). > > In the case of MySql I believe that the length of a varchar only > specifies the maximum length, it does not affect the actual space used > in the db as the data is stored as variable length records. I don''t > know about postgresql. > > ColinIf that were the case, there would be little if any reasonable purpose in specifying VARCHAR() length. What you say may apply to the various text field types, as a buffer of the maximum length would handle a field of any length up to the maximum length... and the data could (best) be stored as the variable length stream -- thus conserving disk space. As to your preceding post:>If you don''t like the field definitions generated by the scaffold then >you can edit the migration before you run it, or run another migration >later.No can do: Scaffold will accept syntax like this: script/generate scaffold amendment c_code:string c_name:string tran_id:integer priority:integer It will not accept syntax like this: script/generate scaffold amendment c_code:varchar(2) c_name:varchar(35) tran_id:tinyint priority:tiny int Nor can you change the field prescriptions in the xxxxdatetimexxxx_amendments.rb schema.>Is there anything in your sql table creation that cannot be >specified in migration code?All of the above. Worse, I have to support huge traffic and humongous amounts of data which make it absolutely essential to conserve disk volume. If deployment happened to translate these incoherent field definitions to my actual production tables, I''d be in huge trouble. But these are just simple, basic concerns for any implementation. Does anybody handle these issues? I''m not asking for the sake of a discussion. Here''s something like what I would like to do in the xxxxdatetimexxxx_amendments.rb schema for instance: class CreateAmendments < ActiveRecord::Migration def self.up create_table :amendments do |t| connection = ActiveRecord::Base.connection() connection.execute(CREATE TABLE amendments (id integer NOT NULL AUTO_INCREMENT PRIMARY KEY, c_code varchar(2), c_name varchar(35), tran_id integer), priority tinyint, created_at datetime, updated_at datetime) ENGINE=InnoDB;) end end So this is a matter of a simple question: Is it feasible to do things this way? To answer that question to the standards the answer will be tested means we know what the ramifications and requisites of doing so are. Do I for instance need to specify the id field and "timestamps" fields (which are actually of course, DATETIME values)? This sort of a technique is what I envisioned having to do to preserve the goals of my design schema. What we''re calling "agile" is abstracting the processes so far away from us, that the abstraction is a huge interference against doing the job right -- unless of course someone can answer this simple question: Is it feasible to do things this way? If not -- that''s certainly not agility. End of story. If so -- how? What do we have to do to negotiate our intentions throughout design, testing, and deployment? Regards, mike -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
As others have posted, modify your migration file before running it if
you are concerned about the size of varchars.
For example, you can do the following,
def self.up
create_table :mytable, :force => true do |t|
t.string :field_name, :null => false, :limit => 50, :default
"Some value"
...
end
end
Look into the foreign_key_migrations gem if you want to setup PK/FK
relationships in your migrations. I have not discovered anything I
can''t handle in a migration for table creation/alteration.
On Mar 22, 3:16 pm, Mike Montagne
<li...-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org>
wrote:> Colin Law wrote:
> > On 22 March 2010 04:43, Mike Montagne
<li...-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:
> >> In the former, you''re not even passing the information to
the
> >> environment to build the tables you want. Of course then,
it''s critical
> >> to convey your intended design to deployment. A varchar(25)
(intended
> >> field designation) requires 1/10th the disk resources that a
string
> >> field (which translates to varchar(255)).
>
> > In the case of MySql I believe that the length of a varchar only
> > specifies the maximum length, it does not affect the actual space used
> > in the db as the data is stored as variable length records. I
don''t
> > know about postgresql.
>
> > Colin
>
> If that were the case, there would be little if any reasonable purpose
> in specifying VARCHAR() length. What you say may apply to the various
> text field types, as a buffer of the maximum length would handle a field
> of any length up to the maximum length... and the data could (best) be
> stored as the variable length stream -- thus conserving disk space.
>
> As to your preceding post:
>
> >If you don''t like the field definitions generated by the
scaffold then
> >you can edit the migration before you run it, or run another migration
> >later.
>
> No can do:
>
> Scaffold will accept syntax like this:
>
> script/generate scaffold amendment c_code:string c_name:string
> tran_id:integer priority:integer
>
> It will not accept syntax like this:
>
> script/generate scaffold amendment c_code:varchar(2) c_name:varchar(35)
> tran_id:tinyint priority:tiny int
>
> Nor can you change the field prescriptions in the
> xxxxdatetimexxxx_amendments.rb schema.
>
> >Is there anything in your sql table creation that cannot be
> >specified in migration code?
>
> All of the above.
>
> Worse, I have to support huge traffic and humongous amounts of data
> which make it absolutely essential to conserve disk volume. If
> deployment happened to translate these incoherent field definitions to
> my actual production tables, I''d be in huge trouble.
>
> But these are just simple, basic concerns for any implementation.
>
> Does anybody handle these issues?
>
> I''m not asking for the sake of a discussion. Here''s
something like what
> I would like to do in the xxxxdatetimexxxx_amendments.rb schema for
> instance:
>
> class CreateAmendments < ActiveRecord::Migration
> def self.up
> create_table :amendments do |t|
> connection = ActiveRecord::Base.connection()
> connection.execute(CREATE TABLE amendments (id integer NOT NULL
> AUTO_INCREMENT PRIMARY KEY, c_code varchar(2), c_name varchar(35),
> tran_id integer), priority tinyint, created_at datetime, updated_at
> datetime) ENGINE=InnoDB;)
> end
> end
>
> So this is a matter of a simple question:
>
> Is it feasible to do things this way?
>
> To answer that question to the standards the answer will be tested means
> we know what the ramifications and requisites of doing so are. Do I for
> instance need to specify the id field and "timestamps" fields
(which are
> actually of course, DATETIME values)?
>
> This sort of a technique is what I envisioned having to do to preserve
> the goals of my design schema. What we''re calling
"agile" is abstracting
> the processes so far away from us, that the abstraction is a huge
> interference against doing the job right -- unless of course someone can
> answer this simple question: Is it feasible to do things this way?
>
> If not -- that''s certainly not agility. End of story.
>
> If so -- how? What do we have to do to negotiate our intentions
> throughout design, testing, and deployment?
>
> Regards,
>
> mike
> --
> Posted viahttp://www.ruby-forum.com/.
--
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.
E. Litwin wrote:> As others have posted, modify your migration file before running it if > you are concerned about the size of varchars. > > For example, you can do the following, > > def self.up > create_table :mytable, :force => true do |t| > t.string :field_name, :null => false, :limit => 50, :default > "Some value" > ... > end > end > > Look into the foreign_key_migrations gem if you want to setup PK/FK > relationships in your migrations. I have not discovered anything I > can''t handle in a migration for table creation/alteration.Primary and foreign key migration is supported. It''s not the issue. Have you found that you can migrate varchar() field types as varchar() field types, instead of strings? If so, how? That would answer the question. -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
E. Litwin wrote:> As others have posted, modify your migration file before running it if > you are concerned about the size of varchars. > > For example, you can do the following, > > def self.up > create_table :mytable, :force => true do |t| > t.string :field_name, :null => false, :limit => 50, :default > "Some value" > ... > end > end > > Look into the foreign_key_migrations gem if you want to setup PK/FK > relationships in your migrations. I have not discovered anything I > can''t handle in a migration for table creation/alteration.------------------------- Quote from resource: Migrations support all the ***basic*** data types: string, text, integer, float, datetime, timestamp, time, date, binary and boolean: string - is for small data types such as a title. text - is for longer pieces of textual data, such as the description. integer - is for whole numbers. float - is for decimals. datetime and timestamp - store the date and time into a column. date and time - store either the date only or time only. binary - is for storing data such as images, audio, or movies. boolean - is for storing true or false values. ------------------------- You don''t see any VARCHAR(), do you? Any TINYINT, SMALLINT, BIGINT, DOUBLE, DOUBLE PRECISION, TINYBLOB, TINYTEXT, BLOB, TEXT, MEDIUMBLOB, MEDIUMTEXT, LONGBLOB, LONGTEXT, ENUM, OR SET do you? Neither do I. We know that MySQL doesn''t support binary -- of course, we use TINYINT with 0 or 1 for false/true respectively. But unless we can specify our schema with an SQL statement, it doesn''t look like there''s much a way even to support many vital schemas, much less migrate them. Is there at trick to coerce scaffolding to create such fields? I haven''t found one or I wouldn''t be asking. Is it "premature optimization" to see I''m going to run into trouble here if I need these field types? Never has been in any other tools I''ve worked with; in fact it''s regular practice. So the question remains, how do you support migration of these vital field types? Answering that does not involve imagining it doesn''t matter, or that we can''t account for it -- and that''s just fine. -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On Mon, Mar 22, 2010 at 4:03 PM, Mike Montagne <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:> So the question remains, how do you support migration of these vital > field types?They are apparently vital to you; do not assume that''s true of every developer and every situation. Yes, you can use your own custom SQL in a migration. If you are so focused on this level of control I have to wonder why you haven''t (apparently) read the API doc for ActiveRecord::Migration. The downside (of at least the examples you''ve used) is you''ve tied yourself to a specific DB vendor''s product. I''ve currently working on more instances than not where multiple vendors are involved. Leaving the DB description in Rails'' abstract form means I can work with those different DBs easily. That''s much more important to *my* projects than saving 253 bytes of disk space somewhere. FWIW, -- Hassan Schroeder ------------------------ hassan.schroeder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org twitter: @hassan -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Hassan Schroeder wrote:> On Mon, Mar 22, 2010 at 4:03 PM, Mike Montagne <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> > wrote: > >> So the question remains, how do you support migration of these vital >> field types? > > They are apparently vital to you; do not assume that''s true of every > developer and every situation. > > Yes, you can use your own custom SQL in a migration. If you are > so focused on this level of control I have to wonder why you haven''t > (apparently) read the API doc for ActiveRecord::Migration. > > The downside (of at least the examples you''ve used) is you''ve tied > yourself to a specific DB vendor''s product. I''ve currently working on > more instances than not where multiple vendors are involved. > > Leaving the DB description in Rails'' abstract form means I can work > with those different DBs easily. That''s much more important to *my* > projects than saving 253 bytes of disk space somewhere. > > FWIW, > -- > Hassan Schroeder ------------------------ hassan.schroeder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org > twitter: @hassanOf course, you recognize the importance then -- "premature optimization" is not about accounting for your issues to the depth of the first 253 bytes... half a dozen columns of half a dozen tables -- some of which may contain up to dozens of millions of records. It''s not about 253 bytes. It''s about 253 bytes per field, per so many records, per so many tables. As to why you''re merging tables from multiple vendors, I have no idea. But certainly still, unless a vendor doesn''t support a vital field type (in which case, your vendor would be chosen for your needed support), there''s no limitation imposed by specifying a data schema you would want to preserve for a great variety of reasons; and certainly neither, would a RoR ability to sustain a needed schema inhibit your development capabilities. On the contrary, *only if you accept the cost of 253 bytes on whatever the scale, at every turn*, would the ability to sustain an intended data schema inhibit your project development -- and then, only to the degree of specifying the translated field types, instead of the specific types most of us require for better reasons. -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On Mon, Mar 22, 2010 at 4:58 PM, Mike Montagne <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:> Of course, you recognize the importance then -- "premature optimization" > is not about accounting for your issues to the depth of the first 253 > bytes... half a dozen columns of half a dozen tables -- some of which > may contain up to dozens of millions of records. II do lots of small projects, where tables may contain, oh, *dozens* of records, maybe *hundreds* :-) Your concern about disk usage simply doesn''t apply.> As to why you''re merging tables from multiple vendors, I have no idea.I''m not talking about "merging tables", I''m talking about running the app on different DBs. That''s simply incompatible with your examples, and is why abstraction of DB characteristics is a good thing for many developers. -- Hassan Schroeder ------------------------ hassan.schroeder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org twitter: @hassan -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Hassan Schroeder wrote:> On Mon, Mar 22, 2010 at 4:03 PM, Mike Montagne <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> > wrote: > > I have to wonder why you haven''t > (apparently) read the API doc for ActiveRecord::Migration. > > FWIW, > -- > Hassan Schroeder ------------------------ hassan.schroeder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org > twitter: @hassanIt''s your assumption that I''m not studying the API documentation. I''ve had the pages opened for days; and I just posted some material from the API documentation. You point would be, that if you had studied the API documentation, and that you knew how it was possible to implement the usual goals of database schemas, you might cite what I''ve missed. I''m waiting for a reply from a developer in India on one possibility (he might know). The closest I''ve found in the API documentation so far is, type_to_sql in ActiveRecord::ConnectionAdapters::MysqlAdapter. Here''s its source implementation: # File lib/active_record/connection_adapters/mysql_adapter.rb, line 493 493: def type_to_sql(type, limit = nil, precision = nil, scale = nil) 494: return super unless type.to_s == ''integer'' 495: 496: case limit 497: when 1; ''tinyint'' 498: when 2; ''smallint'' 499: when 3; ''mediumint'' 500: when nil, 4, 11; ''int(11)'' # compatibility with MySQL default 501: when 5..8; ''bigint'' 502: else raise(ActiveRecordError, "No integer type has byte size #{limit}") 503: end 504: end That''s a far cry from handling all the field types, isn''t it? Or is it? You know how to implement that to produce VARCHAR() ranges from 1..255, even as it isn''t important to you? Why make this a spitting match? Either you know how to do this or you don''t. -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Hassan Schroeder wrote:> On Mon, Mar 22, 2010 at 4:58 PM, Mike Montagne <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> > wrote: > > I''m not talking about "merging tables", I''m talking about running the > app > on different DBs. > > That''s simply incompatible with your examples, and is why abstraction > of DB characteristics is a good thing for many developers. > > -- > Hassan Schroeder ------------------------ hassan.schroeder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org > twitter: @hassanYou''re the first I''ve heard of who is unconcerned with *redundantly* upscaling data storage resources on a scale of 255/2, ostensibly to support an application on different engines, when all you''d have to do to do so properly would be to conditionally implement an explicit schema -- calling such a simple thing "premature optimization." Believe me, I already understand why. -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On Mon, Mar 22, 2010 at 5:21 PM, Mike Montagne <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:> It''s your assumption that I''m not studying the API documentation.Just from the fact that you seemed in doubt whether you could use raw SQL in a migration; the doc has an example of doing just that.> You know how to implement that to produce VARCHAR() ranges from 1..255, > even as it isn''t important to you? > > Why make this a spitting match? Either you know how to do this or you > don''t.Who''s making it a "spitting match"? I do know, and it''s in the document I *already pointed you at* -- the ActiveRecord::Migration API. Simple example: class CreateDogs < ActiveRecord::Migration def self.up create_table :dogs do |t| t.string :name, :limit => 100 t.string :nickname, :limit => 242 t.string :weight, :limit => 5 t.string :country, :limit => 2 t.timestamps end end def self.down drop_table :dogs end end mysql> show create table dogs\G *************************** 1. row *************************** Table: dogs Create Table: CREATE TABLE `dogs` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(100) COLLATE utf8_unicode_ci DEFAULT NULL, `nickname` varchar(242) COLLATE utf8_unicode_ci DEFAULT NULL, `weight` varchar(5) COLLATE utf8_unicode_ci DEFAULT NULL, `country` varchar(2) COLLATE utf8_unicode_ci DEFAULT NULL, `created_at` datetime DEFAULT NULL, `updated_at` datetime DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci 1 row in set (0.00 sec) mysql> -- Hassan Schroeder ------------------------ hassan.schroeder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org twitter: @hassan -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On Mon, Mar 22, 2010 at 5:26 PM, Mike Montagne <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:> You''re the first I''ve heard of who is unconcerned with *redundantly* > upscaling data storage resources on a scale of 255/2, ostensibly to > support an application on different engines, when all you''d have to do > to do so properly would be to conditionally implement an explicit schema > -- calling such a simple thing "premature optimization."I have no idea what you''re going on about -- "ostensibly", as in you don''t believe anyone would ever use different databases at different stages of a single app''s lifecycle? Seriously?> Believe me, I already understand why.? "why" what? -- Hassan Schroeder ------------------------ hassan.schroeder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org twitter: @hassan -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On 23 March 2010 00:21, Mike Montagne <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:> That''s a far cry from handling all the field types, isn''t it?Hasn''t it already been pointed out that out of the box, Rails handles "basic" field types. If you *really* have to do something that isn''t supported out of the box, then run your own SQL - you''ve already posted a contrived example of that yourself, but cleaner method is illustrated under the heading "More Examples" here: http://api.rubyonrails.org/classes/ActiveRecord/Migration.html> Why make this a spitting match? Either you know how to do this or you > don''t.Well, to be fair, I don''t think you''ve been 100% rational in your responses; your replies to people asking for clarification have been rather curt - so part of the responsibility for any "spitting" has to be your own.> You''re the first I''ve heard of who is unconcerned with *redundantly* > upscaling data storage resources on a scale of 255/2, ostensibly to > support an application on different enginesI hate to agree with Hassan, but I guess I''ll be the second person... It''s so much more of a benefit to rapid prototyping to be able to jump from SQLite to MySQL to Oracle to Mongo that the storage costs for not worrying about a few bytes here and there is heavily outweighed. Of course, everyone will agree that if you''re in a position to be concerned about millions of records - then the benefits of the framework flexability aren''t overwhelming at all, and you want to make sure the DB tables are as efficient as possible, but that''s not something that *most* Rails apps face for most of their life. And those that do often end up stopping using lots of the standard Rails features to become as efficient as possible. To come back to your initial post (which don''t forget, Hassan did answer for you), you point out that you''re new to Rails, and then you start to ask how to make Rails do things your way, instead of you taking the time to do things Rails''s way; and trust me (and every post here has said the same thing) - Rails *can* do what you''re asking, but you''re coming at it from the wrong angle. To answer another of your questions; I develop locally using MySQL as I prefer it to SQLite, I don''t really have any problems at all deploying from migrations that do everything I need for all the situations I''ve come across in the last couple of years. Don''t forget, part of the beauty of Rails is that if you''ve chosen a DB platform (which you''ve chosen, because it''s got some essential field type for you) that isn''t supported to the level you''d prefer, you''re perfectly at liberty to write your own adapter file and plug it into your project. There''s no hoops to jump through - just write some Ruby :-) -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Hassan Schroeder wrote:> On Mon, Mar 22, 2010 at 5:21 PM, Mike Montagne <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> > wrote: > > > Who''s making it a "spitting match"? I do know, and it''s in the document > I *already pointed you at* -- the ActiveRecord::Migration API. > > Simple example: > > class CreateDogs < ActiveRecord::Migration > def self.up > create_table :dogs do |t| > t.string :name, :limit => 100 > t.string :nickname, :limit => 242 > t.string :weight, :limit => 5 > t.string :country, :limit => 2 > > t.timestamps > end > end > > def self.down > drop_table :dogs > end > end > > mysql> show create table dogs\G > *************************** 1. row *************************** > Table: dogs > Create Table: CREATE TABLE `dogs` ( > `id` int(11) NOT NULL AUTO_INCREMENT, > `name` varchar(100) COLLATE utf8_unicode_ci DEFAULT NULL, > `nickname` varchar(242) COLLATE utf8_unicode_ci DEFAULT NULL, > `weight` varchar(5) COLLATE utf8_unicode_ci DEFAULT NULL, > `country` varchar(2) COLLATE utf8_unicode_ci DEFAULT NULL, > `created_at` datetime DEFAULT NULL, > `updated_at` datetime DEFAULT NULL, > PRIMARY KEY (`id`) > ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci > 1 row in set (0.00 sec) > > mysql> > > -- > Hassan Schroeder ------------------------ hassan.schroeder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org > twitter: @hassanI''ve had that page opened for days and I don''t see any such example. http://ar.rubyonrails.org/ ??? (It''s a frame, so there''s no exterior link to the particular frame.) A pity, if this really works, the example doesn''t cover the various text field types, which likewise are important to me -- and seemingly wouldn''t be handled by imposing a character (?) limit? Anyway, it looks to me like you''re creating the table at the command line. Which of course will have none of the intended effects on scaffolding/migration. Condescending that it *may* be a good idea (at least a useful idea for one developer?) to have some control over the schema in the RoR environment, please understand that my concerns are covered if I have the necessary control over most of the field types in the schema .rb. That''s what I''m after. After all, I suppose I could remove the up and down code, manage my tables with generic tools (even the command line), and be done with it. Question then, is that what everyone else is doing in RoR? Or does it matter to anyone that they have control of native field types? -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On Mon, Mar 22, 2010 at 5:56 PM, Mike Montagne <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:> I''ve had that page opened for days and I don''t see any such example.It''s not on that page, I just created it for you in *ONE MINUTE* based on the content of the page I keep mentioning.> Anyway, it looks to me like you''re creating the table at the command > line. Which of course will have none of the intended effects on > scaffolding/migration.?? I created it with the migration I pasted in the mail. You can see the result. That was the whole point.> After all, I suppose I could remove the up and down code, manage my > tables with generic tools (even the command line), and be done with it.Sure, you could. Be happy.> Question then, is that what everyone else is doing in RoR?No. Most people use migrations.> Or does it matter to anyone that they have control of native field > types?No. And I''ve tried to explain why. Good luck. -- Hassan Schroeder ------------------------ hassan.schroeder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org twitter: @hassan -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On 23 March 2010 00:56, Mike Montagne <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:> After all, I suppose I could remove the up and down code, manage my > tables with generic tools (even the command line), and be done with it.You know what... that''s exactly what I did for my first Rails app :-) I figured I had so much going on learning Ruby and the framework, that migrations were one step too far at that time, and I just created the DB like I always had in VB... manually.> Question then, is that what everyone else is doing in RoR?NO!! :-) Migrations are a million times better!> Or does it matter to anyone that they have control of native field > types?They do have control... It''s been pointed out to you.. you can run any SQL you like in migrations, while *most* of the time the helpers that cover the basics will cover the majority of the advanced stuff too. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Michael Pavling wrote:> On 23 March 2010 00:21, Mike Montagne <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote: >> That''s a far cry from handling all the field types, isn''t it? > > Hasn''t it already been pointed out that out of the box, Rails handles > "basic" field types. If you *really* have to do something that isn''t > supported out of the box, then run your own SQL - you''ve already > posted a contrived example of that yourself, but cleaner method is > illustrated under the heading "More Examples" here: > http://api.rubyonrails.org/classes/ActiveRecord/Migration.htmlThere''s no cleaner method. Nor the provided example. This is just handling the same incoherent field types.> >> Why make this a spitting match? Either you know how to do this or you >> don''t. > > Well, to be fair, I don''t think you''ve been 100% rational in your > responses; your replies to people asking for clarification have been > rather curt - so part of the responsibility for any "spitting" has to > be your own. >OK, fine. We still don''t have an example of creating a table with the desired schema attributes from within the xxxxDTxxxx_table.rb -- which is obviously what I''m asking for. Information is information. Expressing a lack of information or apathy for the issues doesn''t answer the question.>> You''re the first I''ve heard of who is unconcerned with *redundantly* >> upscaling data storage resources on a scale of 255/2, ostensibly to >> support an application on different engines > > I hate to agree with Hassan, but I guess I''ll be the second person..."Somehow" I expected that.> It''s so much more of a benefit to rapid prototyping to be able to jump > from SQLite to MySQL to Oracle to Mongo that the storage costs for not > worrying about a few bytes here and there is heavily outweighed.Sure, and everywhere you''re upscaling resource consumption on a scale of 255/2, you''re proud of electing to just do that, assuming some add-on is going to restore the performance you destroy for simply disregarding the fundamental principles of table design. Now, you''re preaching it to me, instead of answering the question.> Of course, everyone will agree that if you''re in a position to be > concerned about millions of records - then the benefits of the > framework flexability aren''t overwhelming at all, and you want to make > sure the DB tables are as efficient as possible, but that''s not > something that *most* Rails apps face for most of their life. And > those that do often end up stopping using lots of the standard Rails > features to become as efficient as possible."Somehow" I expected that opinion too. Instead of answering a basic question, you''re excusing a huge shortcoming with your own forfeiture of standards -- and asking me to politely "understand" that, in lieu of real, agile development.> To come back to your initial post (which don''t forget, Hassan did > answer for you),Where''s the answer?> you point out that you''re new to Rails, and then you > start to ask how to make Rails do things your way, instead of you > taking the time to do things Rails''s way; and trust me (and every post > here has said the same thing) - Rails *can* do what you''re asking, but > you''re coming at it from the wrong angle.Really? You mean, lean database design is just a foreign concept to "rails developers," and what I really need to do to get my head on straight, is applaud the forfeiture of principle -- I need to embrace this idea of bloated field design, ostensibly to run on multiple servers with less effort, when all I would have to do so is tailor a few (if any) field specs for these other servers? Wow. If I had only realized that a few million lines of code ago.> To answer another of your questions; I develop locally using MySQL as > I prefer it to SQLite, I don''t really have any problems at all > deploying from migrations that do everything I need for all the > situations I''ve come across in the last couple of years. > > Don''t forget, part of the beauty of Rails is that if you''ve chosen a > DB platform (which you''ve chosen, because it''s got some essential > field type for you)No, no, no, no, no. There''s a whole pile of considerations.> that isn''t supported to the level you''d prefer, > you''re perfectly at liberty to write your own adapter file and plug it > into your project. There''s no hoops to jump through - just write some > Ruby :-)My apologies. I''ve come to the wrong place. -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Michael Pavling wrote:> On 23 March 2010 00:56, Mike Montagne <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote: > > NO!! :-) Migrations are a million times better!Well, Michael, I hate to tell you... back to square one: Obviously, *we''re doing migrations*, and it was the inability to construct all the field types which obviously matters, and raised these questions/concerns.>> Or does it matter to anyone that they have control of native field >> types? > > They do have control... It''s been pointed out to you.. you can run any > SQL you like in migrations, while *most* of the time the helpers that > cover the basics will cover the majority of the advanced stuff too.No example of SQL in a migration has been cited yet. Quote it. Hassan cites a string field limit (and thanks for that); but this doesn''t cover further issues such as text field type. If a method doesn''t cover all the bases, it can''t be deployed. You still have to go back to the command line or local utility and modify the structure... and... unless internalized migration procedures keep their hands off your work forever afterward... then you''re also going to have to isolate those processes from access to your table design. Plain and simple. When VB programmers lecture CPPB guys (who''ve worked in maybe 40 toolsets altogether)... on forfeiting principle... (which I anticipated would be the case here)... well, thanks pal for your 2 cents on you slipping a few lines of code is more worthwhile than cutting resources 125:1. -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On Mon, Mar 22, 2010 at 6:31 PM, Mike Montagne <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:> No example of SQL in a migration has been cited yet.It is on the ActiveRecord::Migration page. As I''ve said. Repeatedly. disframed: <http://api.rubyonrails.org/classes/ActiveRecord/Migration.html> and preceded by the sentence: "And sometimes you need to do something in SQL not abstracted directly by migrations:"> Plain and simple.Yep, plain and simple. If you can''t find it, well, I dunno what to say. -- Hassan Schroeder ------------------------ hassan.schroeder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org twitter: @hassan -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Okay.... I''m done with your posts now... but I hate to be called a liar, so I''ll respond to this one: On 23 March 2010 01:18, Mike Montagne <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:> There''s no cleaner method. Nor the provided example. This is just > handling the same incoherent field types.In the link I pasted for you to it says: "And sometimes you need to do something in SQL not abstracted directly by migrations" and goes on to show a nice clean example of how to execute SQL directly in a migration to do WHATEVER you want if you can''t find the helper that does it for you.> We still don''t have an example of creating a table with the > desired schema attributes from within the xxxxDTxxxx_table.rb -- which > is obviously what I''m asking for. Information is information. Expressing > a lack of information or apathy for the issues doesn''t answer the > question.You must be reading a different thread, because looking up through the conversation, I can see at a glance three examples you''ve been given.>>> You''re the first I''ve heard of who is unconcerned with *redundantly* >>> upscaling data storage resources on a scale of 255/2, ostensibly to >>> support an application on different engines >> >> I hate to agree with Hassan, but I guess I''ll be the second person... > > "Somehow" I expected that.I don''t know how you expected that. You don''t know me. You don''t know Hassan. You don''t know how little I''ve agreed with him in other posts. Your "somehow" is a prejudice that you have and by declaiming it, it''s self-fullfilling. You don''t care about whether anything I''m saying is of any use to you to help you figure your problem out. You''re just slamming me with because I dare to try to remind you of something you already know - that you don''t know Rails well yet - and it might serve you better to listen to those that are trying to nudge you in the right direction.>> It''s so much more of a benefit to rapid prototyping to be able to jump >> from SQLite to MySQL to Oracle to Mongo that the storage costs for not >> worrying about a few bytes here and there is heavily outweighed. > > Sure, and everywhere you''re upscaling resource consumption on a scale of > 255/2, you''re proud of electing to just do that, assuming some add-on is > going to restore the performance you destroy for simply disregarding the > fundamental principles of table design.Yes - and that''s heavily outweighed in *most* cases. Obviously not yours - acknowledged. You''ve said how you have an extremely large dataset and other constraints, and that''s been understood.> Now, you''re preaching it to me, instead of answering the question.You''re not paying me to answer a question. If you''re not happy with me trying to teach you how to solve it for yourself that''s your business.> Instead of answering a basic > question, you''re excusing a huge shortcoming with your own forfeiture of > standards -- and asking me to politely "understand" that, in lieu of > real, agile development.If it''s such a basic question, answer it yourself. It does annoy me that when people don''t like an answer they accuse it of being wrong. Well maybe the question isn''t as "basic" as you think - and some of the other considerations that people have been highlighting are *actually* worth thinking about for two mins.>> To come back to your initial post (which don''t forget, Hassan did >> answer for you), > > Where''s the answer?You asked first about your "rake db:migrate" breaking. Hassan pointed out you need to run "create" first...>> you point out that you''re new to Rails, and then you >> start to ask how to make Rails do things your way, instead of you >> taking the time to do things Rails''s way; and trust me (and every post >> here has said the same thing) - Rails *can* do what you''re asking, but >> you''re coming at it from the wrong angle. > > Really?yes.> You mean, lean database design is just a foreign concept to "rails > developers," and what I really need to do to get my head on straight, is > applaud the forfeiture of principle -- I need to embrace this idea of > bloated field design, ostensibly to run on multiple servers with less > effort, when all I would have to do so is tailor a few (if any) field > specs for these other servers?No... that''s the angle you *are* coming at it from.. and that''s wrong.> Wow. If I had only realized that a few million lines of code ago.<sarcasm ignored... as it''s not really becoming of such an advanced DB developer as yourself (and mine is snider ;-) >>> Don''t forget, part of the beauty of Rails is that if you''ve chosen a >> DB platform (which you''ve chosen, because it''s got some essential >> field type for you) > > No, no, no, no, no. There''s a whole pile of considerations.You misunderstood me. I wasn''t belittling your choice of DB as *just* because of *one* field. I was trying to intimate that I understood there were considerations *such as* field type (and I assume others) that were constraining you.>> that isn''t supported to the level you''d prefer, >> you''re perfectly at liberty to write your own adapter file and plug it >> into your project. There''s no hoops to jump through - just write some >> Ruby :-) > > My apologies. I''ve come to the wrong place.Well, when you get over your passive-aggressive sulk, maybe someone else will answer your next problem. Bye from me. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Hassan Schroeder wrote:> On Mon, Mar 22, 2010 at 5:56 PM, Mike Montagne <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> > wrote: > >> I''ve had that page opened for days and I don''t see any such example. > > It''s not on that page, I just created it for you in *ONE MINUTE* based > on the content of the page I keep mentioning.Well, that isn''t even relevant to my question, is it? I already realize I can do SQL from the command line. I even provided examples of my own (which, rather than being utilized/utilizable from this agile environment, have to be abstracted to expressions which negate the purpose of the SQL statements I provided). Great. Doesn''t answer the question; doesn''t show how to declare native field types in the up method; and yet you''ve already answered my question.>> Anyway, it looks to me like you''re creating the table at the command >> line. Which of course will have none of the intended effects on >> scaffolding/migration. > > ?? I created it with the migration I pasted in the mail. You can see the > result. That was the whole point.OK. So you can generate VARCHARS by imposing a limit on a string declaration. But that doesn''t alleviate the need to declare native types of Text, Blob, and so forth. It gets us a little toward somewhere, but it doesn''t resolve all the issues. Which is what we need to do.>> After all, I suppose I could remove the up and down code, manage my >> tables with generic tools (even the command line), and be done with it. > > Sure, you could. Be happy. > >> Question then, is that what everyone else is doing in RoR? > > No. Most people use migrations.I realize that of course, or someone would have answered how to preserve intended native schemas in the equivalent of an SQL statement in the xxx.rb file. Which means that the folks here don''t give a hoot about native field types and lean table design. OK. I get it. Actually, I anticipated it.>> Or does it matter to anyone that they have control of native field >> types? > > No. And I''ve tried to explain why. > > Good luck. > > -- > Hassan Schroeder ------------------------ hassan.schroeder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org > twitter: @hassanGood luck to you too! :-) And thanks for the try (really); and that limit trick does help some (really). It just doesn''t get me to all the places I need to go. So, right now, it looks like SQL for this. It''s OK how you do this. I''ll do it "the old way." That won''t hold me back a hoot, either I guess. Funny thing though -- I bet not too far down the road you''ll see SQL CREATE statements handled by RoR, even in migrations. Want to bet? Like for no good reason even? :-) Thanks for the try. Have a great day. -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Michael Pavling wrote:> Okay.... I''m done with your posts now... but I hate to be called a > liar, so I''ll respond to this one: > > On 23 March 2010 01:18, Mike Montagne <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote: >> There''s no cleaner method. Nor the provided example. This is just >> handling the same incoherent field types. > > In the link I pasted for you to it says: > "And sometimes you need to do something in SQL not abstracted directly > by migrations" > and goes on to show a nice clean example of how to execute SQL > directly in a migration to do WHATEVER you want if you can''t find the > helper that does it for you. >I''d say bye too... especially when it would have been so simple to paste in the code. -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On Mon, Mar 22, 2010 at 6:57 PM, Mike Montagne <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:> Great. Doesn''t answer the question; doesn''t show how to declare native > field types in the up method; and yet you''ve already answered my > question.Dude, you really aren''t listening. You''ve been given multiple pointers to the page that has an example of *using raw sql in a migration*. You can write whatever db-specific stuff you want.> It''s OK how you do this. I''ll do it "the old way." That won''t hold me > back a hoot, either I guess. Funny thing though -- I bet not too far > down the road you''ll see SQL CREATE statements handled by RoR, even in > migrations.Really, you think? Like they, uh, are already? What a bet. Or wait -- are you actually SENDING MAIL FROM THE PAST? Quick: what year is it where you are? What color is the sky? Oh, man, now this is getting exciting! -- Hassan Schroeder ------------------------ hassan.schroeder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org twitter: @hassan -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On 22 March 2010 22:16, Mike Montagne <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:> Colin Law wrote: >> >> In the case of MySql I believe that the length of a varchar only >> specifies the maximum length, it does not affect the actual space used >> in the db as the data is stored as variable length records. I don''t >> know about postgresql.> If that were the case, there would be little if any reasonable purpose > in specifying VARCHAR() length. What you say may apply to the various > text field types, as a buffer of the maximum length would handle a field > of any length up to the maximum length... and the data could (best) be > stored as the variable length stream -- thus conserving disk space.See http://dev.mysql.com/doc/refman/5.1/en/char.html which clearly states that the space in the db to store a varchar is dependant on the actual length of each string, not the max permitted length. Therefore reducing the limit on a varchar column does not save space in the db. (Assuming the strings themselves are not truncated by changing the limit of course). Colin -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.