This is one of the few points where I disagree with DHH, but then this
is because I usually have more than one thing touching the DB. If it
was only the Rails application using it, maybe then, but I intend to
have other things reading and writing data from the database, so I want
some more things to protect myself from the users.
- Tom M. ([email protected]) [060215 12:48]:
On Feb 15, 2006, at 7:56 AM, Thibaut Barr?re wrote:
Just a survey but how many people actually use transactions in RoR
applications ?Raises hand!
Perhaps it comes from not having started with MySQL, but instead a DB
that supported transactions.
I’ll have to raise my hand as we’re using them too – no way around it.
Rick
http://www.rickbradley.com MUPRN: 196
| a @home address,
random email haiku | and your 65.2.x.x address is well
| within their control.
This is one of the few points where I disagree with DHH, but then this
is because I usually have more than one thing touching the DB. If it
was only the Rails application using it, maybe then, but I intend to
have other things reading and writing data from the database, so I want
some more things to protect myself from the users.
Then you’re not disagreeing with me at all. I too consider clever
databases a must if you integrate through the database. What I’m
saying is that you don’t need to and should not desire to integrate
through the database. There are a world of other integration
opportunities that does not force you to get a clever database.
So its more of an architectural choice (damn, didn’t that sound
enterprise!). I’m saying that integration through the database is a
design smell and you should avoid. IF you’re able to avoid it, then
clever databases makes no sense. If your design, however, is already
smelly, then do stack up on the deodorant. It might not work as well
as just getting clean, but at least the stench won’t be as bad most of
the time.
David Heinemeier H.
http://www.loudthinking.com – Broadcasting Brain
http://www.basecamphq.com – Online project management
http://www.backpackit.com – Personal information manager
http://www.rubyonrails.com – Web-application framework
On Feb 15, 2006, at 10:03 AM, Grant J. wrote:
The only answer to that is, “Stop using the database to enforce
access, integrity, and business rules.” That’s not going to fly in a
lot of places. Particularly an Oracle shop.This is one of the few points where I disagree with DHH, but then
this is because I usually have more than one thing touching the
DB. If it was only the Rails application using it, maybe then,
but I intend to have other things reading and writing data from the
database, so I want some more things to protect myself from the users.
You know, I can completely empathize, because I felt exactly the same
way at first.
However…new applications are the Rails sweet spot. We all love Rails
so much that we’d like to use it all of the time, but if you think about
it, Rails is at its best when you’re creating on a new application where
you can follow all the conventions.
So, if you’re creating a new application, and you want outside access to
the data, it really makes a great deal more sense (particularly moving
into the future) to provide that access via web services (pick your
favorite) and Rails makes that pretty easy to provide.
If you really get down to it, why in the world would anyone build a new
application today predicated on the assumption that other systems will
directly access the data?
That, to me, is extremely bad encapsulation!
We OO people preach encapsulation at code level all of the time, and
then many of us (myself included!) have lately been suggesting breaking
it at the application level, which is just plain wrong.
–
– Tom M.
LOL. DHH, that was awesome.
If you’re unsure what DHH is referring to, the Active Record Basics
chapter of the Agile Web D. with Rails explains it very
nicely.
If you haven’t read all the way through it, you’re undoubtedly missing
out. Yes, you can learn through self-discovery (as I often do), but
the book really does help (whereas some books just plain suck and sit
there gathering dust).
Anyway, thanks for the laugh DHH. 
- Rabbit
In my experience enterprise data are so precious that you don’t
seriously
consider storing them in anything lesser than a fully equipped database
like Oracle. The features of such databases that help us keep data
integrity
and consistency have been around for a long time and have proven to be
useful
and relyable. Using other mechanisms instead of relying on the database
for this is making it difficult to get acceptence for enterprise
applications.
I would be skeptical as well. This does not make it wrong to enforce
some constraints at the application level, either duplicating the
constraint
mechanisms of the database or have it only in the application for
constraints
that would require complex triggers. We do not want to duplicate the
business
logic.
As a matter of fact it will be common that the database is read by
several
applications. It is not a good idea to restrict this to the
rails-application.
But writing might indeed be restricted.
Anyway, I think it’s not the time to go for replacement of Oracle by
mySQL
or postgreSQL in the enterprise now. That might become an issue in a
couple of years from now. But rails can be used now already.
Best regards,
Karl
On Feb 15, 2006, at 12:50 PM, David Heinemeier H. wrote:
database happens in a automatic transaction. And if you’re mixing two
state changes that doesn’t automatically live in the same transaction,
then you’re crazy if you’re not using transactions.
Yes, exactly.
How does this have ANYTHING to do with triggers or stored procedures?!
Doesn’t. My response had nothing to do with triggers or stored
procedures.
Also, MySQL has supported transactions since the 90’ies through
InnoDB. Please don’t repeat urban legends as fact.
Down boy. 
http://dev.mysql.com/doc/refman/4.1/en/news-3-23-34.html
Changes in release 3.23.34 (10 Mar 2001)
Added the INNOBASE storage engine and the BDB storage engine to the
MySQL source distribution.
I didn’t repeat any urban legends. I stated that I started on DBs that
supported them, period. Perhaps could have been more clear by stating
that I started at a time when MySQL didn’t support them.
What I can tell you, without question, is that a spooky number of MySQL
(and probably other DBs) backed applications in Perl, PHP, and likely
Rails too, do not use transactions.
You know, MySQL et. al. could have solved this themselves if they’d
made InnoDB the default, and the MyISAM the option, way back in
antiquity.
Peace, David. Lots of people hate MySQL for bad reasons. As for me, I
only hate it for good reasons.
–
– Tom M.
Changes in release 3.23.34 (10 Mar 2001)
Added the INNOBASE storage engine and the BDB storage engine to the
MySQL source distribution.
Aight. It should have been “only supported transactions for HALF A
DECADE”, then.
I didn’t repeat any urban legends. I stated that I started on DBs that
supported them, period. Perhaps could have been more clear by stating
that I started at a time when MySQL didn’t support them.
That would help frame the argument ;). I’m just sick and tired of
hearing people babble about MySQL’s supposed lack of transactions, so
any reference to that is an instant trigger (drum roll).
What I can tell you, without question, is that a spooky number of MySQL
(and probably other DBs) backed applications in Perl, PHP, and likely
Rails too, do not use transactions.
How on earth does that have anything to do with MySQL? As far as I
know, no database will force transactions upon you. Although, Active
Record will actually force them upon you. Anything happening in a
before_save is automatically wrapped in one, for example.
You know, MySQL et. al. could have solved this themselves if they’d
made InnoDB the default, and the MyISAM the option, way back in
antiquity.
What does MySQL anno pre-2001 have to do with the database choices of
today? So cars in 30’ies didn’t have seat belts, does that have any
baring on the safety of cars today?
Peace, David. Lots of people hate MySQL for bad reasons. As for me, I
only hate it for good reasons.
I can take peace with your other comment in this thread:
We OO people preach encapsulation at code level all of the time, and
then many of us (myself included!) have lately been suggesting breaking
it at the application level, which is just plain wrong.
Couldn’t agree more.
David Heinemeier H.
http://www.loudthinking.com – Broadcasting Brain
http://www.basecamphq.com – Online project management
http://www.backpackit.com – Personal information manager
http://www.rubyonrails.com – Web-application framework
On Feb 15, 2006, at 3:04 PM, David Heinemeier H. wrote:
What I can tell you, without question, is that a spooky number of
MySQL
(and probably other DBs) backed applications in Perl, PHP, and likely
Rails too, do not use transactions.How on earth does that have anything to do with MySQL? As far as I
know, no database will force transactions upon you. Although, Active
Record will actually force them upon you. Anything happening in a
before_save is automatically wrapped in one, for example.
David, it doesn’t have anything to do with MySQL. You’re entire
original response, as well as this paragraph, is colored by the mistaken
assumption that my response had anything do with do with MySQL!
I was just responding to a poll asking whether or not people used
transactions.
That said, it must be true that the MAJORITY of people writing apps
today that store data in SQL databases learned to do so using MySQL,
and probably a large portion of those did so at a time when it didn’t
support transactions. Many were told by MySQL supporters that
transactions really are not all that important. It’s pretty clear the
MySQL community didn’t think transactions were all that important, as
they weren’t added until (relatively) recently.
You know, MySQL et. al. could have solved this themselves if they’d
made InnoDB the default, and the MyISAM the option, way back in
antiquity.What does MySQL anno pre-2001 have to do with the database choices of
today? So cars in 30’ies didn’t have seat belts, does that have any
baring on the safety of cars today?
The default behavior today is still the same, isn’t it?
If you just issue a SQL standard CREATE TABLE command, I’m pretty sure
you end up with a MyISAM table, which doesn’t support transactions,
thereby indirectly suggesting that transactions are either optional or
required in fewer than half the cases.
If I’m wrong about the default behavior, I apologize in advance. Since I
know little about current day MySQL, it’s entirely possible, perhaps
even
likely, that I am wrong. This statement is included to indemnify myself
against suggestions that I am spreading urban legends as fact.
Addtiionally, while it may have no bearing based in technical
reality, it
clearly does have a bearing based upon perception. Everyone on the list
loves Rails, and the people in this thread are trying to move it into
the
Enterprise, where decisions are often made by people with little to no
technical capacity who are driven to a large extent based upon their
perceptions.
The big question I have is not:
Why are MySQL detractors so close minded?
but instead:
Why are MySQL supports to close minded with respect to PostgreSQL?
And…I’ll answer that in advance:
PERCEPTION: MySQL is faster than PostgreSQL.
I’m not even sure if it’s true anymore, and frankly I don’t care for
the same reason you’re sick to death of people asking whether or not
Rails will scale!
PostgreSQL is fast enough, stable enough, standards, compliant enough,
supported enough, careful enough, featured enough, etc. to satisfy ME.
What’s more, it’s been all these things since well before MySQL has had
(non default) support for transactions, and both of us know that’s been
MORE THAN HALF A DECADE.
–
– Tom M.
This mail is fully Buzzword 2.0 compliant, it may
cause violent reactions in some and start flamewars in others. Please
take with a grain of salt</BUZZWORD WARNING>
On 2/15/06, Karl B. [email protected] wrote:
As a matter of fact it will be common that the database is read by several
applications. It is not a good idea to restrict this to the rails-application.
But writing might indeed be restricted.
If you ever have to defend it in a company how about this ?
This is true for database centric architecture, but you could also
consider using a Service Oriented Architecture (SOA), which is all the
rage now in entreprises. Each application has its own database for
which it maintains integrity. All application that want to interact
with the data of a given application use service requests (be they web
services or others).
jean
You know, MySQL et. al. could have solved this themselves if they’d
made InnoDB the default, and the MyISAM the option, way back in
antiquity.What does MySQL anno pre-2001 have to do with the database choices of
today? So cars in 30’ies didn’t have seat belts, does that have any
baring on the safety of cars today?
Extrapolating from my own recent experiences with code I’ve seen in
production that deals with people’s money, I’d bet there are hundreds,
if not thousands or tens of thousands of people out there doing the same
thing - driving their web apps around with no seat belts and brakes that
don’t work that well.
Is that Mysql’s fault? Well, no, not really, but after seeing it often
enough, it leaves a bad taste in your mouth - you come to associate
certain tools with a rather ramshackle, haphazard way of going about
things.
I’m a firm believer in worse is better, but sometimes worse leaves a big
mess, and cleaning it up isn’t fun.
–
David N. Welton
Linux, Open Source Consulting
Just a survey but how many people actually use transactions in RoR
applications ?Raises hand!
Perhaps it comes from not having started with MySQL, but instead a DB
that supported transactions.
What on earth are you guys talking about?! Just by using Active
Record, you’re using transactions. All state changes persisted to the
database happens in a automatic transaction. And if you’re mixing two
state changes that doesn’t automatically live in the same transaction,
then you’re crazy if you’re not using transactions.
How does this have ANYTHING to do with triggers or stored procedures?!
Also, MySQL has supported transactions since the 90’ies through
InnoDB. Please don’t repeat urban legends as fact.
Anyways, we return to your scheduled programming: How to get adoption
of Rails in companies.
David Heinemeier H.
http://www.loudthinking.com – Broadcasting Brain
http://www.basecamphq.com – Online project management
http://www.backpackit.com – Personal information manager
http://www.rubyonrails.com – Web-application framework
On Wed, Feb 15, 2006 at 12:17:27PM -0800, Tom M. wrote:
} On Feb 15, 2006, at 10:03 AM, Grant J. wrote:
}
} >>The only answer to that is, “Stop using the database to enforce
} >>access, integrity, and business rules.” That’s not going to fly in
a
} >>lot of places. Particularly an Oracle shop.
} >
} >This is one of the few points where I disagree with DHH, but then
} >this is because I usually have more than one thing touching the
} >DB. If it was only the Rails application using it, maybe then,
} >but I intend to have other things reading and writing data from the
} >database, so I want some more things to protect myself from the
users.
}
} You know, I can completely empathize, because I felt exactly the
same
} way at first.
}
} However…new applications are the Rails sweet spot. We all love Rails
} so much that we’d like to use it all of the time, but if you think
about
} it, Rails is at its best when you’re creating on a new application
where
} you can follow all the conventions.
That is true… of Rails 1.0. That doesn’t mean that it isn’t worth
striving for a broader sweet spot in subsequent versions.
} So, if you’re creating a new application, and you want outside access
to
} the data, it really makes a great deal more sense (particularly moving
} into the future) to provide that access via web services (pick your
} favorite) and Rails makes that pretty easy to provide.
Errrr… no. Web services are a good way of providing cross-domain RPC,
AJAX support, and certain kinds of client-server interaction. They are a
terrible means of moving large chunks of data around. When you need data
throughput, you need direct database access. This does not mean
permission
to execute arbitrary SQL, however.
} If you really get down to it, why in the world would anyone build a
new
} application today predicated on the assumption that other systems will
} directly access the data?
}
} That, to me, is extremely bad encapsulation!
The encapsulation comes from stored procedures (and maybe triggers). You
provide access to data in very specific, very carefully controlled ways.
The project I am on at work involves a huge database with thousands
(millions?) of persisted objects of dozens of different types. These
persisted objects can only be accessed and affected through stored
procedures. Those stored procedures are actually automatically
generated,
so the development overhead is minimal and there is a consistent
interface
to manipulating any object type. This allows the thick client
application,
the web application, and various small tools to all retrieve and
manipulate
large volumes of data efficiently and safely.
Of course, a Rails application (using ActiveRecord) on top of this
system
would be completely unworkable due to the absolute requirement that all
data access uses stored procedures. This is a shortcoming of
ActiveRecord,
not a design flaw.
} We OO people preach encapsulation at code level all of the time, and
} then many of us (myself included!) have lately been suggesting
breaking
} it at the application level, which is just plain wrong.
Object persistence, which is what ActiveRecord is all about, can be
managed
at various levels. Data integrity, security, and access, however, are
database matters. Use the right tool for the job. The database is the
right
tool for data management, and stored procedures (and triggers) are the
mechanism. Web services are the wrong tool for (local) data access.
} – Tom M.
–Greg
On 2/16/06, Gregory S. [email protected] wrote:
Of course, a Rails application (using ActiveRecord) on top of this system
would be completely unworkable due to the absolute requirement that all
data access uses stored procedures. This is a shortcoming of ActiveRecord,
not a design flaw.
It would be workable, it is just a LOT more work. I’m not that
familiar with how other databases work, but with PostgreSQL, you’d
just create SQL types for each model and SQL functions for each type
of database access you needed, then your AR class would have methods
like:
class Album < ActiveRecord::Base
def find_all
find_by_sql(“SELECT * FROM find_all_albums()”)
end
def find_by_id(id)
find_by_sql([“SELECT * FROM find_album_by_id(?)”, id])
end
def update_name(new_name)
connection.update(sanitize_sql([“SELECT * FROM
update_album_name(?,?)”, id, new_name]))
end
end
It’s possible to use Rails even with a completely locked down
database, but your productivity will drop significantly. It’ll
probably still be higher than doing the same thing in another
framework, though.
On Feb 16, 2006, at 5:17 AM, Gregory S. wrote:
Errrr… no. Web services are a good way of providing cross-domain
RPC,
AJAX support, and certain kinds of client-server interaction. They
are a
terrible means of moving large chunks of data around.
Who says?
When you need data throughput, you need direct database access.
Again, who says? You know, when relational databases were brand new, the
Cobol/ISAM folks laughed at them and said they were impractical because
they were inefficient.
interface
to manipulating any object type. This allows the thick client
application,
the web application, and various small tools to all retrieve and
manipulate
large volumes of data efficiently and safely.
Yes, that’s one way to do it. It was well thought out, and no doubt
is/was
practical and efficient at the time.
Of course, a Rails application (using ActiveRecord) on top of this
system
would be completely unworkable due to the absolute requirement that
all
data access uses stored procedures. This is a shortcoming of
ActiveRecord,
not a design flaw.
No, I certainly wouldn’t call it a design flaw. However, what you’re
saying
is that because it was and is done that way, ActiveRecord should
support
it. That’s pretty much identical to the Cobol/ISAM folks mentioned
above.
I’m willing to bet that many of them said that relational DBs should or
must provide a means of accessing the legacy ISAM DBs that were so
prevalent at the time.
So…it’s possible…that history is repeating itself. Many believe that
we’re about to hoist the abstraction level up a notch to web services,
and it’s possible that they’re right or wrong. It may take a short time
or a long time (though in general technology adoption is happening at an
ever increasing rate).
tool for data management, and stored procedures (and triggers) are the
mechanism. Web services are the wrong tool for (local) data access.
You may be right, I may be right, we may both be wrong.
I, for one, have seen too many statements of absolutely certainty
fall by
the wayside, particularly when they have to do with performance and
effiency.
By those standards, there’s zero chance that Windows/Office will ever
become the enterprise standards. It’s perfectly clear that they are slow
and inefficient! And…besides that…DOS/WordPerfect are the way it’s
done now.
–
– Tom M.
Tom M. wrote:
procedures. Those stored procedures are actually automatically
Yes, that’s one way to do it. It was well thought out, and no doubt is/was
No, I certainly wouldn’t call it a design flaw. However, what you’re
or a long time (though in general technology adoption is happening at an
database matters. Use the right tool for the job. The database is the
right
tool for data management, and stored procedures (and triggers) are the
mechanism. Web services are the wrong tool for (local) data access.
It is a very handy way to get cross platform operation without much in
the way of hassles. I have a 100Mb LAN with several 800MHz computers
(one serving RoR with lighttpd, FCGI and Postgresql) and it takes only a
fraction over 1 second to load up a quite complex page which uses data
from 4 different tables on it. That is quick enough for most business,
and I am sure I could make it faster.
P.S. I know I could also do the app with a custom program and it would
show the same info in a small fraction of a second. But it would need
to be rewritten/recompiled for each different OS/CPU.
Regards Neil.
To return briefly to the scheduled programming again… is there a
good strategy to be gleaned from all this? An enterprise is going to
have issues of legacy data storage, data integrity, platform buy-in,
etc. Let’s say I’m not shooting for instantaneous migration to Rails
for these kinds of issues. If it’s in Java, let it stay in Java. If
it’s stored procedures, then maybe Rails isn’t the right tool right
now. Otherwise, it’s going to be a hard-fought battle, and one that I
am unlikely to win.
However, as John-Mason and Thibaut pointed out, what if I quietly
start developing in Ruby and Rails when it’s clearly the right tool
for the job? The most successful scenario, then, would be applications
that:
- Do not require massive business logic
- Operate on new databases, or existing simple ones
- Need to be developed quickly, and
- Are fairly visible, possibly even eye-poppingly awesome.
That way, when an internal customer gets a great app delivered ahead
of schedule, and can show it off, it builds demand for that
programming model. It’ll be a lot easier to sell something once I’ve
already given it some value.
The downside is the knee-jerk factor - to be considered a liability
for developing in “unsupported” languages, or to be told, explicitly,
“no,” if someone latches on to my use of RoR as a problem.
If I started now, how many great apps could I deliver before someone
noticed that they weren’t written in PHP?
So what do y’all think… will it fly?