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.

-- 
You may need to metaphorically make a deal with the devil.
By 'devil' I mean robot devil and by 'metaphorically' I mean get your coat. - Bender
Rasputin :: Jack of All Trades - Master of Nuns

> 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

On Tue, 23 Nov 2004 20:11:24 +0900, David Heinemeier Hansson
<david@loudthinking.com> wrote:
> > 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.

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
-- 
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

> 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

On Wed, 24 Nov 2004 07:01:17 +0900, David Heinemeier Hansson
<david@loudthinking.com> wrote:
>> 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.

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
-- 
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

Austin Ziegler wrote:
> On Wed, 24 Nov 2004 07:01:17 +0900, David Heinemeier Hansson
> <david@loudthinking.com> wrote:
> 
>>>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.
> 
> 
> 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".

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

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

-- 
Jamis Buck
jgb3@email.byu.edu
http://www.jamisbuck.org/jamis

> 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

On Wednesday, November 24, 2004, 9:23:09 PM, David wrote:

> 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

On Wed, 24 Nov 2004 19:48:18 +0900, Gavin Sinclair
<gsinclair@soyabean.com.au> wrote:
> On Wednesday, November 24, 2004, 9:23:09 PM, David wrote:
> > 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...)

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 * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

On Wed, 24 Nov 2004 19:23:09 +0900, David Heinemeier Hansson
<david@loudthinking.com> wrote:
> > 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.

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
-- 
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

On Nov 24, 2004, at 7:26 AM, Austin Ziegler wrote:

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

> 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

-- 
www.navel.gr | tel: +30 2106898050 | fax: +30 2106898437

web appliction engine: http://www.navel.gr/nitro
have fun: http://www.joy.gr

On Wed, 24 Nov 2004 22:58:09 +0900, George Moschovitis <gm@navel.gr> wrote:
> > 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.

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

-austin
-- 
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

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

On Nov 24, 2004, at 9:24 AM, Austin Ziegler wrote:

> On Wed, 24 Nov 2004 22:58:09 +0900, George Moschovitis <gm@navel.gr> 
> wrote:
>>> 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.
>
> I don't know. I haven't yet played with Nitro or Og. I was actually
> introduced to this problem with ActiveRecord indirectly.
>
> -austin
> -- 
> Austin Ziegler * halostatue@gmail.com
>                * Alternate: austin@halostatue.ca
>
>

Francis Hwang
http://fhwang.net/

On Wed, 24 Nov 2004 23:32:18 +0900, Francis Hwang <sera@fhwang.net> wrote:
> 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

> On Nov 24, 2004, at 9:24 AM, Austin Ziegler wrote:
> 
> > On Wed, 24 Nov 2004 22:58:09 +0900, George Moschovitis <gm@navel.gr>
> > wrote:
> >>> 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.
> >
> > I don't know. I haven't yet played with Nitro or Og. I was actually
> > introduced to this problem with ActiveRecord indirectly.
> >
> > -austin
> > --
> > Austin Ziegler * halostatue@gmail.com
> >                * Alternate: austin@halostatue.ca
> >
> >
> 
> Francis Hwang
> http://fhwang.net/
> 
> 


-- 
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

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

-- 
www.navel.gr | tel: +30 2106898050 | fax: +30 2106898437

web appliction engine: http://www.navel.gr/nitro
have fun: http://www.joy.gr

Jamis Buck <jamis_buck@byu.edu> wrote in message news:<41A412B7.4070603@byu.edu>...
<snip>
> 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.

In theory your are correct.  In reality, no one does this.  In
addition, no one creates tables with duplicate names in the same
schema differing only in case.  If you do, please consider a career
outside of IT.

I don't know exactly how ActiveRecord works, but I would expect any
ORM to just do the right thing when it comes to table/column names and
case, i.e. it shouldn't care.  At least, that's what I would do.

Regards,

Dan

Gavin Sinclair wrote:

>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...)
>
PostgreSQL does the same thing if you put the table/field names in quotes.

Carl

Austin Ziegler <halostatue@gmail.com> wrote in message news:<9e7db91104112404285b9f2477@mail.gmail.com>...
> On Wed, 24 Nov 2004 19:23:09 +0900, David Heinemeier Hansson
> <david@loudthinking.com> wrote:
> > > 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.
> 
> 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

when you select the metadata from Oracle (user_tab_columns), you can
convert
them to lowercase inside the OracleAdapter. You just have to convert
them to lowercase consistently everywhere. 

Quoting tablenames is not a bright idea, imho. 

Rails may have some minor problems with Oracle, but I don't think the
case sensitivity of column names is one of them.

regards, 

-klaus

On Thu, 25 Nov 2004 06:22:59 +0900, Klaus Momberger <klausm0762@yahoo.de> wrote:
> Austin Ziegler <halostatue@gmail.com> wrote in message news:<9e7db91104112404285b9f2477@mail.gmail.com>...
> > On Wed, 24 Nov 2004 19:23:09 +0900, David Heinemeier Hansson
> > <david@loudthinking.com> wrote:
> > > > 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.
> > 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.
> when you select the metadata from Oracle (user_tab_columns), you can
> convert them to lowercase inside the OracleAdapter. You just have to convert
> them to lowercase consistently everywhere.

Yes. That still doesn't fix that MySQL is broken as an application,
and people who are using MySQL after years of experience with real
databases will run into problems because of ActiveRecord's assumptions
and some of the brain-dead tools out there for MySQL.

> Quoting tablenames is not a bright idea, imho.

It's still legal, and should be dealt with properly.

> Rails may have some minor problems with Oracle, but I don't think the
> case sensitivity of column names is one of them.

It is one, as of right now.

-austin
-- 
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

On Thu, 25 Nov 2004 06:45:33 +0900,
Austin Ziegler <halostatue@gmail.com> wrote:
>
> Yes. That still doesn't fix that MySQL is broken as an application,

I wish people would stop exaggerating. Choosing the right job
for the tool at hand results in a lot more working programs.
Is Ruby broken because it's not Perl-compatible? Is Objective-C
broken because it can't cope with C++ code?

Sleep well, everybody.
s.

On Thu, Nov 25, 2004 at 08:48:00AM +0900, Stefan Schmiedl wrote:
> I wish people would stop exaggerating. 
> Choosing the right job for the tool at hand results in a lot more working programs.

I for one will keep looking for a job that suits my hammer.

;)

-- 
Hassle-free packages for Ruby?
RPA is available from http://www.rubyarchive.org/

Stefan Schmiedl wrote:
> 
> I wish people would stop exaggerating. Choosing the right job
> for the tool at hand results in a lot more working programs.
> Is Ruby broken because it's not Perl-compatible? Is Objective-C
> broken because it can't cope with C++ code?

Of course, the right tool for the right job, but what if I handed you a 
screwdriver carved out of celery?  MySQL incorporates "SQL" in its name, 
but it does not begin to implement the SQL that the vast majority of SQL 
developers have accepted.  I wouldn't use MySQL as the standard of 
comparison for the rest of the SQL world any more than I would try to 
build a house using a child's scribbles.

In case it's not clear, I agree very strongly with Austin in this 
debate.  SQL is a mature and well-documented language that deserves some 
respect.  There is a great deal of power that can be leveraged by 
embracing the SQL standard, and ignoring that standard is a wasted 
opportunity.

On the other hand, Rails is young and growing, and we shouldn't be too 
discouraging just because the author can't fix everything at once.  :) 
I would venture to guess that case-sensitivity in table names is not a 
very hard problem to deal with.  If I can figure it out, I'll do what I can.

-- 
Glenn Parker | glenn.parker-AT-comcast.net | <http://www.tetrafoil.com/>

On Thu, 25 Nov 2004 09:34:33 +0900,
Glenn Parker <glenn.parker@comcast.net> wrote:
> Stefan Schmiedl wrote:
>> 
>> I wish people would stop exaggerating. Choosing the right job
>> for the tool at hand results in a lot more working programs.
>> Is Ruby broken because it's not Perl-compatible? Is Objective-C
>> broken because it can't cope with C++ code?
>
> Of course, the right tool for the right job, but what if I handed you a 
> screwdriver carved out of celery?

I'd try to preserve it as a sample of craftmanship.
If you expected me to really work with it, I'd try to preserve you as a 
sample of a completely different kind ;->

> MySQL incorporates "SQL" in its name, 
> but it does not begin to implement the SQL that the vast majority of SQL 
> developers have accepted.  I wouldn't use MySQL as the standard of 
> comparison for the rest of the SQL world any more than I would try to 
> build a house using a child's scribbles.
>
> In case it's not clear, I agree very strongly with Austin in this 
> debate.  SQL is a mature and well-documented language that deserves some 
> respect.  There is a great deal of power that can be leveraged by 
> embracing the SQL standard, and ignoring that standard is a wasted 
> opportunity.

Borland Database Engine (BDE) SQL, ODBC SQL, MS Jet SQL, MS SQLServer T-SQL:
All claim to accept (some variant of) SQL where you can easily stumble
over more or less subtle differences. If you're lucky, they are caught
as errors by the receiving server, if not, you get some very interesting
bugs to hunt for.

All I expect of something called SQL is that the basic keywords and
syntax are there. Everything else I look up when I work with it.

To veer off on a tangent, what I'd really like to see is a database
engine offering somewhat more oriented towards the original ideas of
relational algebra than SQL does. The implementation used in Suneido
(www.suneido.com, probably still windows only) is very interesting, IMO.

Enough. On to other things.
s.

Hi,

yeah I only can agree. I've started learning ruby a few weeks ago and read
an article about rails in a german linux magazine and suddenly tried: It's
really great!

Sometimes it seems to be a little bit slow, but the time I need to develop a
small webapplication is really short. And: Ruby and rails are just at the
beginning. The performance will be more and more better in the future.

So: Great work!

Mike

> Sometimes it seems to be a little bit slow, but the time I need to 
> develop a
> small webapplication is really short. And: Ruby and rails are just at 
> the
> beginning. The performance will be more and more better in the future.

The next release is a MAJOR step forward in the speed department for 
development. It used to be that Rails was pretty slow for development 
(~1 reg/sec), but then really fast in production.

Now with advances in library management, it's possible to use FCGI, 
mod_ruby, and cached WEBrick for development. This means that its MUCH, 
MUCH faster. Really a joy to work with. I can't wait to get 0.9 out 
with it.
--
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

Hi,

thank you for your answer! Sounds really great! Can't wait installing and
testing it :)

Mike

>> Sometimes it seems to be a little bit slow, but the time I need to
>> develop a
>> small webapplication is really short. And: Ruby and rails are just at
>> the
>> beginning. The performance will be more and more better in the future.
> 
> The next release is a MAJOR step forward in the speed department for
> development. It used to be that Rails was pretty slow for development
> (~1 reg/sec), but then really fast in production.
> 
> Now with advances in library management, it's possible to use FCGI,
> mod_ruby, and cached WEBrick for development. This means that its MUCH,
> MUCH faster. Really a joy to work with. I can't wait to get 0.9 out
> with it.
> --
> 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

David Heinemeier Hansson <david@loudthinking.com> wrote:

> I can't wait to get 0.9 out with it.

And I can't stop thinking that, somehow, a "Programming Rails, The
pragmatic programmer's guide" would be one hell of a cherry on top of
the cake. :)

-- 
Luc Heinrich - lucsky@mac.com

> And I can't stop thinking that, somehow, a "Programming Rails, The
> pragmatic programmer's guide" would be one hell of a cherry on top of
> the cake. :)

Be careful what you wish for... ;)
--
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

> thank you for your answer! Sounds really great! Can't wait installing 
> and
> testing it :)

It's already possible now, today, to taste... THE FUTURE!!!

Or with less dramatics, you can do "gem update -s 
http://gems.rubyonrails.org", and all the dandy beta gems will be 
installed on your system. You'll have to look at the changelogs to get 
an idea of what has changed, though:

http://dev.rubyonrails.org/trac.cgi/file/trunk/actionpack/CHANGELOG
http://dev.rubyonrails.org/trac.cgi/file/trunk/activerecord/CHANGELOG
http://dev.rubyonrails.org/trac.cgi/file/trunk/railties/CHANGELOG
--
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

* Luc Heinrich <lucsky@mac.com> [1123 16:23]:
> David Heinemeier Hansson <david@loudthinking.com> wrote:
> 
> > I can't wait to get 0.9 out with it.
> 
> And I can't stop thinking that, somehow, a "Programming Rails, The
> pragmatic programmer's guide" would be one hell of a cherry on top of
> the cake. :)

Rails has got the mindshare at the minute, I'd expect
someone to be on it soon.

Reloadable FCGI will be a real boon (though last time I 
tried out Struts I went for a smoke between HTTP requests,
it was that slow).

-- 
Yeah, well I'm gonna build my own themepark! With blackjack
aaand Hookers!  Actually, forget the park. And the blackjack. - Bender
Rasputin :: Jack of All Trades - Master of Nuns

What would the relationship be between Struts (servlet-based) and FCGI 
(cgi container)?

Also, Struts is actually pretty lightweight- it doesn't really do that 
much. I'd expect you had another issue?

Cheers,
Nick

Dick Davies wrote:

>* Luc Heinrich <lucsky@mac.com> [1123 16:23]:
>  
>
>>David Heinemeier Hansson <david@loudthinking.com> wrote:
>>
>>    
>>
>>>I can't wait to get 0.9 out with it.
>>>      
>>>
>>And I can't stop thinking that, somehow, a "Programming Rails, The
>>pragmatic programmer's guide" would be one hell of a cherry on top of
>>the cake. :)
>>    
>>
>
>Rails has got the mindshare at the minute, I'd expect
>someone to be on it soon.
>
>Reloadable FCGI will be a real boon (though last time I 
>tried out Struts I went for a smoke between HTTP requests,
>it was that slow).
>
>  
>

I just installed the beta on my Mac OS X G4 450MHz box, and I'm ecstatic.

My page loads during development went from 8-10 seconds to mostly < 1 
seconds.

Singe page loads, rough estimates:
0.8.5 rails Webrick, no caching: 8-10 seconds
0.8.5 rails Webrick, -c (not usable for development before): 4-5 seconds
Beta rails, webbrick, -c (caching): < 1 second

Cool. Now I can use my Mac for rails development!

Thanks,
Nick

David Heinemeier Hansson wrote:

>> thank you for your answer! Sounds really great! Can't wait installing 
>> and
>> testing it :)
>
>
> It's already possible now, today, to taste... THE FUTURE!!!
>
> Or with less dramatics, you can do "gem update -s 
> http://gems.rubyonrails.org", and all the dandy beta gems will be 
> installed on your system. You'll have to look at the changelogs to get 
> an idea of what has changed, though:
>
> http://dev.rubyonrails.org/trac.cgi/file/trunk/actionpack/CHANGELOG
> http://dev.rubyonrails.org/trac.cgi/file/trunk/activerecord/CHANGELOG
> http://dev.rubyonrails.org/trac.cgi/file/trunk/railties/CHANGELOG
> -- 
> 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
>
>

thats awesome news, nice to see that it works *that* well.


On Fri, 26 Nov 2004 14:00:56 +0900, Nicholas Van Weerdenburg
<nick@activehitconsulting.com> wrote:
> I just installed the beta on my Mac OS X G4 450MHz box, and I'm ecstatic.
> 
> My page loads during development went from 8-10 seconds to mostly < 1
> seconds.
> 
> Singe page loads, rough estimates:
> 0.8.5 rails Webrick, no caching: 8-10 seconds
> 0.8.5 rails Webrick, -c (not usable for development before): 4-5 seconds
> Beta rails, webbrick, -c (caching): < 1 second
> 
> Cool. Now I can use my Mac for rails development!
> 
> Thanks,
> Nick
> 
> 
> 
> David Heinemeier Hansson wrote:
> 
> >> thank you for your answer! Sounds really great! Can't wait installing
> >> and
> >> testing it :)
> >
> >
> > It's already possible now, today, to taste... THE FUTURE!!!
> >
> > Or with less dramatics, you can do "gem update -s
> > http://gems.rubyonrails.org", and all the dandy beta gems will be
> > installed on your system. You'll have to look at the changelogs to get
> > an idea of what has changed, though:
> >
> > http://dev.rubyonrails.org/trac.cgi/file/trunk/actionpack/CHANGELOG
> > http://dev.rubyonrails.org/trac.cgi/file/trunk/activerecord/CHANGELOG
> > http://dev.rubyonrails.org/trac.cgi/file/trunk/railties/CHANGELOG
> > --
> > 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
> >
> >
> 
> 


-- 
Tobi
http://blog.leetsoft.com

* Nicholas Van Weerdenburg <nick@activehitconsulting.com> [1108 02:08]:

> What would the relationship be between Struts (servlet-based) and FCGI 
> (cgi container)?
> 
> Also, Struts is actually pretty lightweight- it doesn't really do that 
> much. I'd expect you had another issue?

Well, I'll leave aside the lightweightness of Struts, I never got into it
enough to know better - it was a 12Mb download last time I looked though.

I'm really talking about performance in development on rails and
tomcat, the bottleneck in question with struts development is jsp
compilation as far as I can make out. I always quite liked the servlet API,
but JSPs (which is where struts focusses, that and custom taglibs).

The jsp two-step compile has always been a bit of a kludge IMO,
I always wonder whose idea that was....

(I know technically you could use something else for the view, but this is 
'hello world' we're talking about now....)


But it's the same fundamental problem, how often you poll for code changes.
I remember Ara or Carl (on that rubygarden fastcgi page) had a trick that
let your fastcgi classes detect when their *.rb file had changed and reload
themselves, I'm assuming that might have benn involved here.

> Dick Davies wrote:
> >Reloadable FCGI will be a real boon (though last time I 
> >tried out Struts I went for a smoke between HTTP requests,
> >it was that slow).

-- 
zzz..Kill all humans. Kill all humans..zzz .....
I was having the most wonderous dream. You were in it. - Bender
Rasputin :: Jack of All Trades - Master of Nuns

> But it's the same fundamental problem, how often you poll for code 
> changes.
> I remember Ara or Carl (on that rubygarden fastcgi page) had a trick 
> that
> let your fastcgi classes detect when their *.rb file had changed and 
> reload
> themselves, I'm assuming that might have benn involved here.

That would be auto-reload.rb. I'm not using that here as it had a bunch 
of other issues. And frankly, I could get away with way Less Software. 
All the framework code and infrastructure is loaded using require, 
which is then cached for the remainder of the interpreters life cycle.

But all the application code is using "load", which means that it'll 
reevaluate everything on each request. This turns out to be pretty 
cheap even for "big" applications like Basecamp. It was much more 
expensive to parse the Rails framework AND create a new Ruby process.

There are a few drawbacks to this approach, but all something that can 
be learnt to live with:

1) Load is just reopening existing classes and overwriting behavior. 
This doesn't work for removing methods. You'll still have to restart 
the server there. Luckily, the times where it makes a difference 
whether a method was actually removed (instead of just not used) are 
few and far in between.

2) Your model class definitions have to be idempotent (it doesn't 
matter for controllers since they're defined in an anonymous module for 
other reasons). Passing the class definition twice must not have 
side-effects. Currently, I lack to deal with one case in Active Record 
where this is not the case (using the macro-based callbacks).
--
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

* David Heinemeier Hansson <david@loudthinking.com> [1139 10:39]:
> >But it's the same fundamental problem, how often you poll for code 
> >changes.
> >I remember Ara or Carl (on that rubygarden fastcgi page) had a trick 
> >that
> >let your fastcgi classes detect when their *.rb file had changed and 
> >reload
> >themselves, I'm assuming that might have benn involved here.
> 
> That would be auto-reload.rb.

Sorry, by mistake - I meant for  fastcgi not modruby, should have typed
'detect when their *.fcgi file had changed', see:

http://www.rubygarden.org/ruby?FCGIRubyWhyArentMyChangesDisplayed

> 1) This doesn't work for removing methods.
> 2) Your model class definitions have to be idempotent 

That's a small price to pay, so long as the docs mention to restart
the webserver if things look screwy.

Thanks for the headsup.

-- 
That question was less stupid; though you asked it in a profoundly stupid way. - Prof. Farnsworth
Rasputin :: Jack of All Trades - Master of Nuns