rails is awesome

[Dick Davies]

Couldn't help sending a big 'thank you' to DHH for Rails.

I finally threw away CVS ruby so I could try it on 1.8, and
it's stupidly easy to use.

I finally get a chance to get to grips with MVC without all that
taglib nonsense filling up slots in my head....

Good work, fella.

 

[David Heinemeier Hansson]

Couldn't help sending a big 'thank you' to DHH for Rails.

Thanks, Dick. Oh, and do stay tuned. The upcoming release (0.9)
features a wide-array of powerful improvements, such as using
FCGI/mod_ruby/cached WEBrick as a development platform (instead of slow
CGI), dynamic fixtures, breakpoint support, better environment support,
and much more.

Exciting times.
--
David Heinemeier Hansson,
http://www.basecamphq.com/ -- Web-based Project Management
http://www.rubyonrails.org/ -- Web-application framework for Ruby
http://macromates.com/ -- TextMate: Code and markup editor (OS X)
http://www.loudthinking.com/ -- Broadcasting Brain

 

[Austin Ziegler]

Thanks, Dick. Oh, and do stay tuned. The upcoming release (0.9)
features a wide-array of powerful improvements, such as using
FCGI/mod_ruby/cached WEBrick as a development platform (instead of slow
CGI), dynamic fixtures, breakpoint support, better environment support,
and much more.

David,

I haven't seen this myself, but from something said by others, it
appears that ActiveRecord may actually have a few minor issues with
cased table and column names. If I have a column "Id" it should be
treated the same as "id". I'm a bit busy with tidying up Ruwiki 0.9.0
for release to verify myself, but I thought it'd be worth mentioning.

-austin

 

[David Heinemeier Hansson]

I haven't seen this myself, but from something said by others, it

appears that ActiveRecord may actually have a few minor issues with
cased table and column names.

Yes, this issue is that Active Record dictates you to use lower-case
. Neither databases nor Ruby is case-insensitive, I don't think I
want to put that in Active Record. The idea is that the table and the
class bear close resemblance.

Hence, Active Record also proclaims that thy shall use lower-cased and
underscores for composite words. So CreditRating is turned into
credit_ratings.

If you really wanted to, you could overwrite all of that, though. You
can overwrite the id column used with Model.id_column() and the table
name with Model.table_name().

In the mean time, I'll be playing the flute
--
David Heinemeier Hansson,
http://www.basecamphq.com/ -- Web-based Project Management
http://www.rubyonrails.org/ -- Web-application framework for Ruby
http://macromates.com/ -- TextMate: Code and markup editor (OS X)
http://www.loudthinking.com/ -- Broadcasting Brain

 

[Austin Ziegler]

Yes, this issue is that Active Record dictates you to use
lower-case . Neither databases nor Ruby is case-insensitive, I
don't think I want to put that in Active Record. The idea is that
the table and the class bear close resemblance.

Erm. SQL databases *are* case-insensitive on the names. MySQL may
not be, but that's a problem with MySQL, not RDBMSes in general. In
Oracle, at least, there's no difference between ID, Id, and id for a
column or table name.

Essentially, David, this is a *problem* with ActiveRecord.
ActiveRecord is in the wrong here if it's being case-sensitive to
the database's meta-data in the general case.

I don't disagree with many other design decisions you've made --
enforce the lower-case behaviour in the Ruby side, certainly, and I
agree with the decision for underscores -- but the reality is that
ActiveRecord is in the wrong for case-sensitivity on the database
side.

Hence, Active Record also proclaims that thy shall use lower-cased
and underscores for composite words. So CreditRating is turned
into credit_ratings.

That's fine, for the Ruby side. But credit_ratings and
CREDIT_RATINGS on the database side are one and the same.
ActiveRecord must be smart enough to do this.

If you really wanted to, you could overwrite all of that, though.
You can overwrite the id column used with Model.id_column() and
the table name with Model.table_name().

I shouldn't have to, for this. I agree with your assertions
regarding naming schemes in general (e.g., it has to be
credit_ratings and not credit_rating) but -- at the risk of majorly
repeating myself -- SQL databases are case insensitive. It's a
MySQL so-called extension (really, it's a screwup on their part)
that makes SQL case-sensitive on their part.

Compare:
http://qurl.net/7z (MySQL)
http://qurl.net/7y (MySQL)
http://qurl.net/7x (Sybase: see "Case sensitivity of identifiers")
http://qurl.net/7A (FirebirdSQL: see "Double-quoted identifiers")

Sorry, but I lived and breathed real RDBMS systems for a few years,
and MySQL is wrong (and inconsistent! -- it depends on the
underlying filesystem, not on the inherent nature of the database).
If ActiveRecord's behaviour is based on that, then ActiveRecord
needs to change.

-austin

 

[Jamis Buck]

Erm. SQL databases *are* case-insensitive on the names. MySQL may
not be, but that's a problem with MySQL, not RDBMSes in general. In
Oracle, at least, there's no difference between ID, Id, and id for a
column or table name.

I'm definately not a DB expert, but I believe in this case Oracle, at
least, *is* case sensitive. Consider:

create table "credit_rating" (
...
);

create table "CREDIT_RATING" (
...
);

The above would create two distinct tables.

The keywords are case insensitive, but the column and table names can be
made case sensitive by putting them in quotes. If you omit the quotes,
the identifier is uppercased automatically.

Essentially, David, this is a *problem* with ActiveRecord.
ActiveRecord is in the wrong here if it's being case-sensitive to
the database's meta-data in the general case.

I don't disagree with many other design decisions you've made --
enforce the lower-case behaviour in the Ruby side, certainly, and I
agree with the decision for underscores -- but the reality is that
ActiveRecord is in the wrong for case-sensitivity on the database
side.

That's a bit strong, Austin. David made a decision and has enforced that
decision. If you want to use database identifiers that are mixed case,
you are in no way compelled to use ActiveRecord. AR was designed (and
David has made this clear repeatedly) to enforce certain application
design decisions, to make it easier to rapidly build apps. I believe he
has also said, specifically, that he wants to avoid the trap of having
AR "do everything".

That's fine, for the Ruby side. But credit_ratings and
CREDIT_RATINGS on the database side are one and the same.
ActiveRecord must be smart enough to do this.

Again, not necessarily. Some DB's would see those as the same, others
might not, depending on how the tables were created.

I'm not saying I agree with all of David's decisions regarding AR and
Rails, but where I disagree it is a matter of personal preference. He
made certain decisions, and they _work_. That's really what matters, I
think.

- Jamis

 

[David Heinemeier Hansson]

Essentially, David, this is a *problem* with ActiveRecord.

ActiveRecord is in the wrong here if it's being case-sensitive to
the database's meta-data in the general case.

Active Record places a number of naming constraints of your database.
Just treat the forced lower-case as one such. In the databases where Id
is the same as ID and credit_ratings as CREDIT_RATINGS, it should then
be no problem to rename the fields. For cases where it is significant,
like the database I choose to use for all my projects, it's nice just
to be consistent and not have code to massage cases.

Remember, Active Record is first and foremost an ORM mapper for new
applications. There are some options to tweak the mapping, but they're
really only there for grace and flute playing. Active Record is
basically unashamed to strongly suggest (or even mandate) a naming
convention that'll lead to less software for me to write and maintain.
And less configuration for you to contemplate.

...but the reality is that ActiveRecord is in the wrong for
case-sensitivity on the database side.

I don't think reality have too much to do with our opinions here . I
fully recognize that other choices could have been made for the naming
conventions in Active Record -- given another designer. I don't
recognize my choices to be "wrong" by them being different that yours
would have been.

But I'm glad you're passionate enough about Active Record to construct
a reality around how you think it should be designed. I think a lot of
good design decisions can be made when such a reality is picked and
held dear. But when giving recommendations on a piece of software one
didn't write, it's usually prudent to examine the other guys reality
before constructing your own

Active Record is a MySQL-driven ORM mapper. It now has adapters for
PostgreSQL, SQLite, and latest SQL Server, but they all derive from the
principles of the original MySQL driver. So in the eyes of Active
Record, databases that deviate from the MySQL-way are the ones that are
"wrong" and special programming is needed in their adapters to emulate
MySQL behavior. That's the reality picked

Sorry, but I lived and breathed real RDBMS systems for a few years,
and MySQL is wrong (and inconsistent! -- it depends on the
underlying filesystem, not on the inherent nature of the database).
If ActiveRecord's behaviour is based on that, then ActiveRecord
needs to change.

Jamis Buck had an example from Oracle also being case sensitive, so it
seems to be somewhat more widespread than just MySQL. And as I said,
Active Record was founded on MySQL, so when behavior differs between
RDBMS, AR will side by MySQL by default (strong pressures might revert
that default, but I don't think this is a strong pressure).

Thanks for sharing your opinions, though, Austin.
--
David Heinemeier Hansson,
http://www.basecamphq.com/ -- Web-based Project Management
http://www.rubyonrails.org/ -- Web-application framework for Ruby
http://macromates.com/ -- TextMate: Code and markup editor (OS X)
http://www.loudthinking.com/ -- Broadcasting Brain

 

[Gavin Sinclair]

Jamis Buck had an example from Oracle also being case sensitive, so it
seems to be somewhat more widespread than just MySQL. And as I said,
Active Record was founded on MySQL, so when behavior differs between
RDBMS, AR will side by MySQL by default (strong pressures might revert
that default, but I don't think this is a strong pressure).

I was suprised with Jamis's Oracle examples; I always thought Oracle
was case-insensitive up the wazoo. But I guess I never tried quoting
table names etc. (yeah, *that's* intuitive...)

Also, I was surprised by Austin's use of Sybase to back up the "SQL
databases are case-insensitive" claim. When I worked with Sybase ~6
years ago, it was certainly case-sensitive. The meme in the office at
the time was that Sybase was different from most other DBs in this
regard, and we had to be careful about this when migrating data.

Gavin

 

[Austin Ziegler]

I was suprised with Jamis's Oracle examples; I always thought Oracle
was case-insensitive up the wazoo. But I guess I never tried quoting
table names etc. (yeah, *that's* intuitive...)

That's the point -- SQL92 introduced the quoted format to specifically
allow for case sensitivity. If ActiveRecord is generating its SQL such
that it does:

SELECT "foo" FROM "CREDIT_RATING";

Then it's doing it right -- if ugly. The problem is that the SQL92
syntax requires that if you are going to use quoted SQL identifier
names, you ALWAYS have to use quoted SQL identifier names, even when
creating the tables. See, with Jamis's example of "CREDIT_RATINGS" and
"credit_ratings", both of those tables would have to be quoted in all
SQL regarding that. I don't know if ActiveRecord does that, to be
quite honest -- I haven't delved into the details. If I have
credit_ratings and "CREDIT_RATINGS", then there's no way that I can
get at "CREDIT_RATINGS" unless I always quote it. Simply doing:

1) SELECT * FROM CREDIT_RATINGS
2) SELECT * FROM credit_ratings
3) SELECT * FROM "CREDIT_RATINGS"

1 and 2 are the same. 3 is the only one that refers to the
"CREDIT_RATINGS" table.

The reality is that MySQL is a crap database that doesn't follow
proper SQL92 conventions, and the semantics of this cause a mismatch
in expectations and behaviours. Even SQLServer doesn't behave as badly
as MySQL.

Also, I was surprised by Austin's use of Sybase to back up the "SQL
databases are case-insensitive" claim. When I worked with Sybase ~6
years ago, it was certainly case-sensitive. The meme in the office at
the time was that Sybase was different from most other DBs in this
regard, and we had to be careful about this when migrating data.

I googled for answers because all of my Oracle references are now at
work. I understand that David is using MySQL semantics here, but as
I've said, MySQL is wrong. If the goal is to make ActiveRecord more
widely accepted, then the naming convention thing is going to have to
be dealt with. Frankly, I have stuff that I'd love to do using
ActiveRecord -- but can't even consider it with this broken behaviour.

-austin

 

[Austin Ziegler]

Active Record places a number of naming constraints of your database.
Just treat the forced lower-case as one such. In the databases where Id
is the same as ID and credit_ratings as CREDIT_RATINGS, it should then
be no problem to rename the fields. For cases where it is significant,
like the database I choose to use for all my projects, it's nice just
to be consistent and not have code to massage cases.

When you select the metadata from Oracle, if you have not quoted your
table names when creating them, they will be returned all uppercase.

Thus, ActiveRecord is broken for any likely Oracle application.

-austin

 

[Francis Hwang]

If the goal is to make ActiveRecord more
widely accepted, then the naming convention thing is going to have to
be dealt with. Frankly, I have stuff that I'd love to do using
ActiveRecord -- but can't even consider it with this broken behaviour.

I think DHH has been fairly clear in targeting ActiveRecord for certain
kinds of ORM uses, but not all of them, which is a very respectable
decision to make. If ActiveRecord isn't going to do what you want it to
do, maybe it's worth considering that ActiveRecord is not not the only
ORM in the Ruby sea, and that any of those other ORMs would probably
love to have you as a user/tester/maybe-patcher.

Francis Hwang
http://fhwang.net/

 

[George Moschovitis]

do, maybe it's worth considering that ActiveRecord is not not the only

ORM in the Ruby sea, and that any of those other ORMs would probably
love to have you as a user/tester/maybe-patcher.

is there a similar problem with the Og ORM library? There are no naming
conventions.

regards,
George Moschovitis

 

[Austin Ziegler]

is there a similar problem with the Og ORM library? There are no naming
conventions.

I don't know. I haven't yet played with Nitro or Og. I was actually
introduced to this problem with ActiveRecord indirectly.

-austin

 

[Francis Hwang]

Austin, what DB are you using anyway? Dunno if I caught that in this
thread.

I don't know. I haven't yet played with Nitro or Og. I was actually
introduced to this problem with ActiveRecord indirectly.

-austin

Francis Hwang
http://fhwang.net/

 

[Austin Ziegler]

Austin, what DB are you using anyway? Dunno if I caught that in this
thread.

My issue is more related to a theoretical mismatch because AR encodes
MySQL semantics specifically -- which are *broken* semantics (MySQL is
not SQL92 compliant because SQL92 explicitly states that
case-sensitivity in identifiers is only achievable with quotes around
the identifiers).

In practice, with a putative Oracle connector to AR, AR simply won't
work, because Oracle's metadata tables always return the data in
uppercase -- unless the table name is quoted.

MySQL is a bad model -- it doesn't actually do much of anything right.\

-austin

 

[George Moschovitis]

I don't know. I haven't yet played with Nitro or Og. I was actually

introduced to this problem with ActiveRecord indirectly.

I think there is no such problem with Og. Why dont you have a look
btw

-g.

 

[Dick Davies]

In practice, with a putative Oracle connector to AR, AR simply won't
work, because Oracle's metadata tables always return the data in
uppercase -- unless the table name is quoted.

MySQL is a bad model -- it doesn't actually do much of anything right.\

And you just found this out?
Have you been living in a cave for the last 5 years?

As a postgresql advocate (I started with pgsql over mysql because
a) I wanted to learn SQL, not mySQL
b) in those days mysql had a *lot* of missing features
c) I'm perverse when it comes to choosing the underdog
)

I have to say I'm pleased there's any support for postgres in there at all -
I have a mysqldb running alongside my postgresql one purely for supporting
the dozens of great open source projects that don't dig pgsql, or are stuck
with mysql because it's got its tentacles so deep into the codebase that
no one wants to go through abstracting it out.

[ JDBC thinks it makes this easier, but IMO that's just marketroid hypnosis ]

And these are usually the guys who wrote the project, so being a lazy kind of
sysadmin I slap on mysql and make obscene gestures at it when I need a break
from typing...

From my very limited experience of Rails (almost 24 hours now, woot!) it
seems to expect a fair bit from the database structure, especially in
naming conventions. I don't really see this issue as any different.

I'm assuming there's a way to customize those assumptions in ActiveRecord,
or the adapter. If that's a bit low-level and/or hackish, I'd say that
should be on the feature wishlist for later versions as much as SQL
compliance, since expecting new users to rebuild their database to support
a new MVC kid in town is easily as unrealistic as persuading them to switch
from oracle to mysql....

[ Incidentally can I make it clear here I'm not slagging rails, David.
I have no wish to be its new maintainer ]

 

[Austin Ziegler]

And you just found this out?
Have you been living in a cave for the last 5 years?

No, I've known it for a long time. I just didn't realise until the
last couple of days that ActiveRecord embeds MySQL semantics into its
otherwise nice data modeling techniques.

-austin

 

[Francis Hwang]

And you just found this out?
Have you been living in a cave for the last 5 years?

As a postgresql advocate (I started with pgsql over mysql because
a) I wanted to learn SQL, not mySQL
b) in those days mysql had a *lot* of missing features
c) I'm perverse when it comes to choosing the underdog
)

Other than the wonky SQL-MySQL compliance divide, are there specific
features that you can get out of PostgreSQL, or are a lot easier to use
in PostgreSQL, that might encourage a MySQL user like myself to change?
I've seriously considered switching to PostgreSQL 'cause it has a good
rep with people I trust, but every time I try to Google this topic I
never find something that convinces me to switch.

Francis Hwang
http://fhwang.net/

 

[Dick Davies]

No, I've known it for a long time. I just didn't realise until the
last couple of days that ActiveRecord embeds MySQL semantics into its
otherwise nice data modeling techniques.

Sorry, I'm being flippant because I'm creating a db for rails to use, so
I don't see this as a big issue. Having a legacy DB would probably sober
me up.

But surely even then this shouldn't affect many people?
(my class still starts with a capital letter, right? And how many people
have a customers and a Customers table? )

Strikes me it would bite more people switching from mysql -> sql92 than
going the other way.
(Incidentally, does windows still have case-insensitive filenames?)


The main concerns I have with mysql-centricity are more data-related -
- does mysql still do case-insensitive string searches these days?

But again, I'd see the postgres (or oracle, etc, etc) adapter as the
place to scatter a little 'tablename'.casecmp() magic to fix that..

Anyway, I do feel your pain, Austin.