Issues RUNNING mysql gem

Hassan S. wrote:

On Mon, Mar 22, 2010 at 4:58 PM, Mike M. [email protected]
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 S. ------------------------ [email protected]
twitter: @hassan

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.”

Believe me, I already understand why.

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:
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 engines

I 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 :slight_smile:

Hassan S. wrote:

On Mon, Mar 22, 2010 at 5:21 PM, Mike M. [email protected]
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 S. ------------------------ [email protected]
twitter: @hassan

I’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?

On 23 March 2010 00:56, Mike M. [email protected] 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 :slight_smile:
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!! :slight_smile: 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.

On Mon, Mar 22, 2010 at 5:56 PM, Mike M. [email protected]
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 S. ------------------------ [email protected]
twitter: @hassan

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:
http://api.rubyonrails.org/classes/ActiveRecord/Migration.html

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 :slight_smile:

My apologies. I’ve come to the wrong place.

On Mon, Mar 22, 2010 at 6:31 PM, Mike M. [email protected]
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 S. ------------------------ [email protected]
twitter: @hassan

Michael P. wrote:

On 23 March 2010 00:56, Mike M. [email protected] wrote:

NO!! :slight_smile: 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.

On Tue, 2010-03-23 at 02:31 +0100, Mike M. wrote:

Or does it matter to anyone that they have control of native field
command line or local utility and modify the structure… and… unless
125:1.


http://api.rubyonrails.org/classes/ActiveRecord/Migration.html

find ‘More Examples’ for an example on using Raw SQL for migrations.

Most people make their initial foray into Rails doing something simple
to get a basic feel for how things work, especially if they don’t have
knowledge of the Ruby language. If they did have knowledge of the Ruby
language, they could inspect the source code.

Craig


This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

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 M. [email protected] 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 :wink: >

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 :slight_smile:

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.

Michael P. 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 M. [email protected] 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.

Hassan S. wrote:

On Mon, Mar 22, 2010 at 5:56 PM, Mike M. [email protected]
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 S. ------------------------ [email protected]
twitter: @hassan

Good luck to you too!

:slight_smile:

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?

:slight_smile:

Thanks for the try. Have a great day.

On Mon, Mar 22, 2010 at 6:57 PM, Mike M. [email protected]
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 S. ------------------------ [email protected]
twitter: @hassan

On 22 March 2010 22:16, Mike M. [email protected] wrote:

Colin L. 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