Michael P. wrote:
On 23 March 2010 00:21, Mike M. [email protected] 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:
ActiveRecord::Migration
There’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.
>