Richard C. wrote:
If DHH went mental over prepared statements he could satisfy
maybe 1% of the Rails community who care.
A plugin that extends ActiveRecord is just about the easiest kind to
write. All the tutorials show how to do the ‘acts_as_*’ trick. So how
about…
acts_prepared
?
–
Phlip
http://c2.com/cgi/wiki?ZeekLand ← NOT a blog!!
Well,
answer to WHY should you choose Ruby on Rails over PHP is ,
Rails is well developed web application framework that follows
M-V-C(Model-View-Controller) architecture.
It avoids mixing of Presentation Layer, Business Layer and Data Layer.
Jeniffer F.
Phlip wrote:
I allowed, “I do not have time to do the research” to possibly mean,
“because I expect I will soon be manually configuring CGI handlers,
manually writing redundant details, manually building SQL
strings, manually copying fields out of database records, manually
copying form values out of POSTs, and manually testing.” Maybe I’m
being charitable, but he did mention experience with PHP.
Amen! 
Cheers
Mohit.
Java does scale upwards well, and downwards poorly. I agree.
However, I can use 1/3 of the CPU on my database server with a Java
front end that I can with a Rails front end, given the same
transaction load. That means that on the database server I can either
buy 1/3 the hardware, or support 3 times the transactions load. It is
important when the hardware is more expensive than the programmers.
On the other hand, the average Rails application does not need to
handle that work load. The typical Rails application is run in an
environment where the programmer is expensive but the hardware is
cheap.
Line count is only part of the equation - the other part is efficient
use of machine resources.
Ruby can use the resources efficiently, and as Rails matures I expect
that it will be tuned to be competitive with other platforms.
On 2/14/07, r [email protected] wrote:
On Feb 14, 5:13 am, Jamal S. [email protected]
wrote:and have a lovely syntax!
Does anyone else find that this is not sufficient to describe the
effect of Ruby language?
Agree. Well written Ruby code and Rails code in particular should
practically read like english. You know its written well when your
non-coding Dad can kind of half follow it.
I’ve heard the effect distorted(minimized) by resistant Java
programmers as “syntactic sugar”.
To work in Java at some of the extreme ends of its syntax abuse
spectrum requires that you do one of three things:
1 - burn out the parts of your brain that can appreciate syntax elegance
2 - perversely alter the parts of your brain to reverse your evaluation
of elegance (elegant = ! isElegant() )
3 - isolate yourself from the mainstream rules for elegance, and derive
an entire value spectrum that lives wholly in the ugly end
While I appreciate the usefulness of Java, the category 2 people
have split many normally healthy java programmers into the first
and last groups.
But I don’t know the word or description to counter the
minimization. Mostly I’m in shock that a programmer could be exposed
to Ruby and still be spewing such distortions.
Career protection denial. Java takes a monstrous amount of your
career investment in technology. Its not easy to take all at once,
seeing years of specialisation erode like that. So you get sniping
comments like that from idiots, whereas smarter Java programmers
smell the coffee and diversify their skills (like they should have
been doing anyway).
Career protection denial. Java takes a monstrous amount of your
career investment in technology. Its not easy to take all at once,
seeing years of specialisation erode like that. So you get sniping
comments like that from idiots, whereas smarter Java programmers
smell the coffee and diversify their skills (like they should have
been doing anyway).
Of course, JRuby getting direct support from Sun, will pull Ruby into
the mainstream of Java. Since Rails is the current benchmark for Ruby
language compliance, when JRuby will run Rails well, we can expect it
to be shipped as a standard part of the JRE.
At last benchmark, JRuby was performing just about twice as fast as
standard Ruby when the JIT compile is enabled. It runs Rails with
occasional errors, so it is not ready for release yet. I anticipate
that the JRE will become the preferred platform for Ruby in a couple
of years.
I agree. I have been monitoring this, and believe that within a year
Prepared Statements will be fully supported in Rails. With MySQL’s
acquisition of Netfrastructure, we can expect many of the oddities of
My-SQL to disappear over a couple of years and My-SQL to become a
technical leader as well as a market force.
Prepared Statements should be a relatively painless migration that
would be transparent to most users. Richard C.'s note following
yours illustrates a simple migration path.
On Feb 14, 10:02 am, “Richard C.” [email protected]
On Feb 14, 8:48 am, “Isak H.” [email protected] wrote:
I.e. not the scalability part (which isn’t ), but the
transaction/atomicity issues you’ve been working on.Isak
It’s been long enough that I’d have to dig it out again. I’m not
trying to ignore this, it’s just been long enough that I have
forgotten the details.
The short form is that MySQL defines the transaction boundary to be
equivalent to the statement boundary. Since the Rails user base is
primarily My-SQL users, the presumption is that the statement boundary
is the transaction boundary. This led to some odd effects with the
version of Rails that I first worked with.
To be totally fair, I will have to try again with a current
installation of Rails.
unknown wrote:
I agree. I have been monitoring this, and believe that within a year
Prepared Statements will be fully supported in Rails.
I am very interested in the potential for prepared statement support in
Rails.
An earlier poster implied that 1% of the Rails community cares about
this, but I think it’s fair to say, that no matter what kind of app.
you’re building, you probably need to hit a database, and if you’re
moving any kind of data volume around, using prepared statements will
save a ton. I think it should be way up there on the priority list as a
way to improve scalability with virtually no extra developer time
required to learn how to use it (I assume that everyone knows how to
take advantage of/understands why prepared statements are good).
Where can I look online to track how prepared statement support is
heading? I am very aware of JRuby and obviously, being able to use JDBC
drivers would be one way to go.
Thanks,
Wes G.
johnso… wrote:
Java does scale upwards well, and downwards poorly. I agree.
Miss-understanding here. A language that minimizes code lines scales
upward easily.
However, I can use 1/3 of the CPU on my database server with a Java
front end that I can with a Rails front end, given the same
transaction load. That means that on the database server I can either
buy 1/3 the hardware, or support 3 times the transactions load. It is
important when the hardware is more expensive than the programmers.
That is the LAMP formula. But I thought hardware was cheaper than
programmers.
On 2/14/07, Wes G. [email protected] wrote:
An earlier poster implied that 1% of the Rails community cares about
this, but I think it’s fair to say, that no matter what kind of app.
you’re building, you probably need to hit a database, and if you’re
moving any kind of data volume around, using prepared statements will
save a ton. I think it should be way up there on the priority list as a
way to improve scalability with virtually no extra developer time
required to learn how to use it (I assume that everyone knows how to
take advantage of/understands why prepared statements are good).
It’s an interesting phenomenon: critics poking at obvious untapped
potential
in Active Record with an “if only AR did this, it would be great”
mindset.
Those actually using Rails tend to be more concerned with the controller
and
rendering mechanics. We have a saying sufficiently common to merit an
acronym: JDM. It Just Doesn’t Matter. AR is good enough to get the job
done
and get out of our way. There are plenty of other untapped avenues to
greatness (REST was mentioned earlier in the thread), so poking around
with
AR plumbing starts looking like a staid, thankless, unjustifiable chore.
Those who don’t know Rails find it easiest to get a handle on and
therefore
criticize Active Record. This is the essence of bike shedding.
If these improvements are truly your number one kickass feature, by all
means pursue them. Rails has a strong track record of growth through
community contribution. I’m disappointed that these common criticisms of
Active Record haven’t turned into fixes and features like so many other
pain
points have. I assume it’s because they aren’t actually painful, they
just
look bad. Until you care about them more than ‘on paper’ I guarantee
nothing
will change.
On that tack, we need better database drivers to really do a good job
with
bound args and prepared statements. Both mysql and postgres bindings are
woefully behind the times with their respective API. Neither supports
their
native binary protocol, for example. But both do enough for AR to get
its
job done.
The bundled mysql.rb has limped along with spotty compatibility for
years
now. All of one person have stood up and worked on it. The rest of us
gem install mysql and get to work building web apps.
Best,
jeremy
On 2/15/07, [email protected] [email protected] wrote:
trying to ignore this, it’s just been long enough that I have
Rails simply delegates transaction handling to the database.
Sounds to me like your issues stem from using mysql with a table type
that doesn’t support transactions.
Either switch to a proper db, or spend some time with the mysql docs
and figure out how to enable transaction support.
Java does have an edge over Ruby/Rails when it comes to distributed
transactions, which afaik there’s no library/clean/simple way to
support in RoR atm, but then again, most of us shouldn’t be working
against multiple db’s.
HTH,
Isak
On Feb 14, 8:43 pm, “Phlip” [email protected] wrote:
That is the LAMP formula. But I thought hardware was cheaper than
programmers.
Have you priced a maxed out IBM 900 series application server with 90%
average utilization recently? Even without the necessary software
license leases, you can buy a lot of programmers for the price of the
bare system lease. When you start adding software licenses ranging
from $150,000 per year per CPU per title, to make the system useful
and maintainable, things get much worse in a hurry.
As per an earlier note, it is rare that Rails programs have to deal
with this scale of system. Most rails programmers don’t have to deal
with anything but commodity systems.
On Feb 15, 2:27 am, “Jeremy K.” [email protected] wrote:
On 2/14/07, Wes G. [email protected] wrote:
It’s an interesting phenomenon: critics poking at obvious untapped potential
in Active Record with an “if only AR did this, it would be great” mindset.Those actually using Rails tend to be more concerned with the controller and
rendering mechanics. We have a saying sufficiently common to merit an
acronym: JDM. It Just Doesn’t Matter. AR is good enough to get the job done
and get out of our way. There are plenty of other untapped avenues to
greatness (REST was mentioned earlier in the thread), so poking around with
AR plumbing starts looking like a staid, thankless, unjustifiable chore.
In your shop it doesn’t matter. In my shop, it keeps Ruby and Rails
from even getting on the radar. I agree that mucking around the AR
plumbing is a thankless task, but it is one that would be worthwhile
to me since my company would stand to save a bundle of money through
improved time to delivery if we could afford to operate Rails apps.
As it is, even free, Rails is too expensive to operate for me to be
able to justify it, even if it does make it trivial to put together a
top-notch web app.
If these improvements are truly your number one kickass feature, by all
means pursue them. Rails has a strong track record of growth through
community contribution. I’m disappointed that these common criticisms of
Active Record haven’t turned into fixes and features like so many other pain
points have. I assume it’s because they aren’t actually painful, they just
look bad. Until you care about them more than ‘on paper’ I guarantee nothing
will change.
Yes, I could do the work. Eventually I might do it (unless someone
else does it first) but the entire Rails community would need to be
involved in establishing the standards, or it would be a mess. As I
posted earlier, there are others working on this problem already, and
they have been talking about their work on this list. I expect a
resolution within a year. However, like others, I have to spend the
bulk of my time pursuing my paid work, and right now that is Java,
xslt, C#, and COBOL.
On that tack, we need better database drivers to really do a good job with
bound args and prepared statements. Both mysql and postgres bindings are
woefully behind the times with their respective API. Neither supports their
native binary protocol, for example. But both do enough for AR to get its
job done.
JRuby with JDBC drivers should take care of that! :o)
The Fire-ruby driver (for Firebird) works very well.
The bundled mysql.rb has limped along with spotty compatibility for years
now. All of one person have stood up and worked on it. The rest of usgem install mysqland get to work building web apps.
MySQL is good for the backing store for mostly static data for a web
app (wikipedia), but it does not meet the needs of core business
functions (large volumes of financial records) yet. Transactional
integrity is important when you are posting data that must pass audit
no matter what happens to the system. People go to jail when you get
so-called “partial commits”. When MySQL starts pushing the
Netfrastructure back end (effectively running an enhanced version of
Firebird under the MySQL API), it will have a chance to play in that
arena.
I bet this is already a lot more research than the original poster
expected to do! :o)
On Feb 15, 3:03 am, “Isak H.” [email protected] wrote:
On 2/15/07, [email protected] [email protected] wrote:
Either switch to a proper db, or spend some time with the mysql docs
and figure out how to enable transaction support.
I use Firebird at home, and the top three commercial RDBMS’ at work.
When MySQL is running the Netfrastructure back end (aka a revamped
Firebird) I will look at it again.
Thanks.
On Feb 15, 1:33 am, Wes G. [email protected]
wrote:
Where can I look online to track how prepared statement support is
heading? I am very aware of JRuby and obviously, being able to use JDBC
drivers would be one way to go.
This list
[email protected] wrote the following on 15.02.2007 09:53 :
On Feb 14, 8:43 pm, “Phlip” [email protected] wrote:
That is the LAMP formula. But I thought hardware was cheaper than
programmers.Have you priced a maxed out IBM 900 series application server with 90%
average utilization recently?
I’m interested by the kind of workload where an IBM 900 has been
actually measured to be more cost efficient that cheap Intel/AMD based
pizza-boxes frontends (web/application servers) accessing a more
expensive database server like:
This is an honest question, I’m not familiar at all with the kind of
performance you can get from an IBM 900, I only know the (huge) price
difference.
Even if there are workloads which are sweet spots for mainframes, I’m
quite sceptic with the mainframe ability to scale cost effectively for
web applications: adding processing power costs a lot compared to adding
just a cheap pizza box for another frontend.
Lionel
You got the breakdown correctly.
Pizza boxes make great front end processors, but they do not handle
database tranactioning on the scale of the big iron. When you have
large scale real-time process management problems with dynamic data,
it is time to bring in the big iron for the back end processing.
Walmart, for example, feeds an array of 900’s from arrays of “pizza
boxes” to manage, in real time, cash flow and inventory from every
one of their operations in the world. The “pizza boxes” act as front
end processors, while the 900’s do the database work. A Walmart
employee may address a web (or terminal) app through one of the “pizza
boxes”, but that “pizza box” addresses data from the database server
which is one or more of the 900’s.
Some arrays of pizza boxes run web apps, while others run other sorts
of front ends.
Does this help?
On Feb 15, 3:34 am, Lionel B. [email protected]
Jeremy K. wrote:
On 2/14/07, Wes G. [email protected] wrote:
It’s an interesting phenomenon: critics poking at obvious untapped
potential
in Active Record with an “if only AR did this, it would be great”
mindset.Those actually using Rails tend to be more concerned with the controller
and
rendering mechanics. We have a saying sufficiently common to merit an
acronym: JDM. It Just Doesn’t Matter. AR is good enough to get the job
done
and get out of our way. There are plenty of other untapped avenues to
greatness (REST was mentioned earlier in the thread), so poking around
with
AR plumbing starts looking like a staid, thankless, unjustifiable chore.
I agree with some of your points. However, I’d like to add that it is
because I am “actually using Rails” (and have been for a year) that I
find these features to be important. I’ve been using prepared DB
statements to optimize DB access for over 10 years on innumerable
platforms/deployment scenarios and I don’t have access to them in AR -
feels like I’m taking a step back.
I’d love to work on this when I get some time. As it stands, I’ve
submitted two (admittedly small) patches on ActiveRecord::Base in the
last 6 months. Maybe I will give it a try. Thanks for the
encouragement.
Wes
Hi –
On Wed, 14 Feb 2007, Richard C. wrote:
Agree. Well written Ruby code and Rails code in particular should
practically read like english. You know its written well when your
non-coding Dad can kind of half follow it.
It’s nice when that happens – and lots of Ruby does have that “almost
like English” feel – but I wouldn’t make too much of it as a
criterion of code quality per se. It can bog you down in concerns
that will never really play out. Rails certainly plays up the quasi-
natural-language aspects of Ruby, and to good effect, but there’s also
a lot of very elegant, idiomatic Ruby code around that doesn’t read
like English – and that’s OK too 
David
–
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
(See what readers are saying! http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs