Issues RUNNING mysql gem

rubyonrails-talk
21

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?

22

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:

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:

23

Hassan Schroeder 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

> 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)

>

-- Hassan Schroeder ------------------------ hassan.schroeder@gmail.com 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?

24

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.

25

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.

26

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

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

27

Michael Pavling 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.

28

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&gt;

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.

29

Michael Pavling 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.

30

Okay.... I'm done with your posts now... but I hate to be called a liar, so I'll respond to this one:

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.

31

Hassan Schroeder 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@gmail.com 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.

32

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:

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.

33

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!

34

See MySQL :: MySQL 8.0 Reference Manual :: 11.3.2 The CHAR and VARCHAR Types 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