Rails - Mar 2006 - DRY principle form validations

We are wondering how you''d validate a credit card number or a SSN 
without writing Javascript and Ruby code.

Would it be through Rails'' AJAX support?

-- 
Posted via http://www.ruby-forum.com/.

You can use validates_format_of and a regular expression

<http://api.rubyonrails.com/classes/ActiveRecord/Validations/ClassMethods.html#M000686>

jt

On 3/13/06, Cody Skidmore <hopefulskeptic@mailinator.com>
wrote:
> We are wondering how you''d validate a credit card number or a SSN
> without writing Javascript and Ruby code.
>
> Would it be through Rails'' AJAX support?

John Tsombakos wrote:
> You can use validates_format_of and a regular expression
> 
>
<http://api.rubyonrails.com/classes/ActiveRecord/Validations/ClassMethods.html#M000686>
> 
> jt
Thank you for the reply.

This looks like it happens on post for the page.  It would be great to 
improve the user experience by notifying them when something on the page 
is invalid as quickly as possible (that being without posting the entire 
page).  It looks like the only way to do that is through AJAX.

Maybe this just isn''t much of a big deal as bandwidth becomes less of
an
issue for users.  Someone has proposed to me that making a user wait for 
a couple of seconds to find out a credit card number is invalid reduces 
the user experience, and wants to know if there is a better way to 
validate the card number other than posting the entire page.

It seems like the only way to do so is through RoR''s AJAX support.

It might be possible to use the events on the input tag to look up the 
credit card information a.s.a.p when enough information is entered.

-- 
Posted via http://www.ruby-forum.com/.

Seems like s terrific addition to Rails would be validates_ methods
which generate both server-side and client-side validation, where
possible.

On 3/13/06, Cody Skidmore <hopefulskeptic@mailinator.com>
wrote:
> John Tsombakos wrote:
> > You can use validates_format_of and a regular expression
> >
> >
<http://api.rubyonrails.com/classes/ActiveRecord/Validations/ClassMethods.html#M000686>
> >
> > jt
>
> Thank you for the reply.
>
> This looks like it happens on post for the page.  It would be great to
> improve the user experience by notifying them when something on the page
> is invalid as quickly as possible (that being without posting the entire
> page).  It looks like the only way to do that is through AJAX.
>
> Maybe this just isn''t much of a big deal as bandwidth becomes less
of an
> issue for users.  Someone has proposed to me that making a user wait for
> a couple of seconds to find out a credit card number is invalid reduces
> the user experience, and wants to know if there is a better way to
> validate the card number other than posting the entire page.
>
> It seems like the only way to do so is through RoR''s AJAX support.
>
> It might be possible to use the events on the input tag to look up the
> credit card information a.s.a.p when enough information is entered.
>
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

Avdi Grimm wrote:
> Seems like s terrific addition to Rails would be validates_ methods
> which generate both server-side and client-side validation, where
> possible.
Think of the drool that would cause.  :o)

-- 
Posted via http://www.ruby-forum.com/.

You wouldn''t need AJAX at all, actually, IMO. But, I''m kind of
confused
since you say you don''t want JavaScript, but the J in AJAX stands for
JavaScript. *shrug*

What I''d suggest if you want instant feedback on the form is to use the
onBlur attriblte on the input field to exectute some validation javascript
in addition to the back end check that you do. You should have both to
account for users who have JS disabled, or get around it some how. For stuff
that is sensitive like this, I''d prefer a code level check and throw
them
back to the form as opposed to an instant check. But, if you are only
checking the formatting, like a SSN is xxx-xx-xxxx or that a credit card
number is yyyyyyyyyyyyyyyy then you might be ok with java script.

Ryan

On 3/13/06, Cody Skidmore <hopefulskeptic@mailinator.com>
wrote:
>
> Avdi Grimm wrote:
> > Seems like s terrific addition to Rails would be validates_ methods
> > which generate both server-side and client-side validation, where
> > possible.
>
> Think of the drool that would cause.  :o)
>
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>


--
Ryan Prins
rprins@gmail.com
http://www.lazyi.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060313/89137fa0/attachment.html

Ryan Prins wrote:
> You wouldn''t need AJAX at all, actually, IMO. But, I''m
kind of confused
> since you say you don''t want JavaScript, but the J in AJAX stands
for
> JavaScript. *shrug*
> 
> What I''d suggest if you want instant feedback on the form is to
use the
> onBlur attriblte on the input field to exectute some validation 
> javascript
> in addition to the back end check that you do. You should have both to
> account for users who have JS disabled, or get around it some how. For 
> stuff
> that is sensitive like this, I''d prefer a code level check and
throw
> them
> back to the form as opposed to an instant check. But, if you are only
> checking the formatting, like a SSN is xxx-xx-xxxx or that a credit card
> number is yyyyyyyyyyyyyyyy then you might be ok with java script.
> 
> Ryan
Thank for the feedback Ryan.  Yeah, I''m aware of what the acronym
stands
for.  I [thought] the Rails framework had built in AJAX support to 
eliminate most of the need for writing Javascript.  It in fact, makes 
AJAX ridiculously simple.  :o)

What we want to avoid is writing server-side code to validate fields, 
and then adding our own Javascript a second time to validate the data on 
the client.  One of the key points to all this is "Don''t Repeat 
Yourself".  If the only way to do it is to write the validation code 
twice, you''re violating the DRY principle right?

Personally, I prefer validating on the server-side also.  My application 
will be a large business application, and I [should] be able to require 
customers to have broadband.  Internet latency could still be a problem, 
but returning validation errors shouldn''t take more than a second, so I
don''t really see the problem.

In any case, if there is a technique to improve response even further, I 
need to find it.

-- 
Posted via http://www.ruby-forum.com/.

> What we want to avoid is writing server-side code to validate fields,
> and then adding our own Javascript a second time to validate the  
> data on
> the client.  One of the key points to all this is "Don''t
Repeat
> Yourself".  If the only way to do it is to write the validation code
> twice, you''re violating the DRY principle right?
This is the unfortunate case when you can''t help repeating yourself.  
If the server is not validating the data as it comes in then someone  
could conceivably reproduce the post action of your form and force  
invalid data into any field. Javascript is the only way to get  
instant feedback, but if you are relying solely on javascript for  
validation then you can be assured someone can weasel around it.

You could try playing with observe_field and see if you can have it  
call your validation on that field, but you will likely have to  
redraw much of the page to have consistent validation messages and I  
can imagine any lag in this process will cause data loss. Not to  
mention this could be much more difficult than adding a little  
javascript validation.

-John

--
John Smilanick
Computing Staff - Webmaster
Kavli Institute for Theoretical Physics
University of California, Santa Barbara
jsmilani@kitp.ucsb.edu
(805) 893-6307


On Mar 13, 2006, at 4:15 PM, Cody Skidmore wrote:


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060314/15b8d647/attachment.html

On 3/14/06, John Smilanick <jsmilani@kitp.ucsb.edu>
wrote:
> This is the unfortunate case when you can''t help repeating
yourself. If the
> server is not validating the data as it comes in then someone could
> conceivably reproduce the post action of your form and force invalid data
> into any field. Javascript is the only way to get instant feedback, but if
> you are relying solely on javascript for validation then you can be assured
> someone can weasel around it.
You''re missing the point of DRY.  It''s not that actions are
never
duplicated, but that we only *write* it once, in one place.  If a
validates_* method could be used to generate both server-side and
client-side (JavaScript) validation, then it would be a very DRY
solution.  The validation might be repeated, but we only write the
validation requirement once.

~Avdi

This seems wrong.


On 16/03/2006, at 3:55 AM, Avdi Grimm wrote:
> On 3/14/06, John Smilanick <jsmilani@kitp.ucsb.edu> wrote:
>> This is the unfortunate case when you can''t help repeating  
>> yourself. If the
>> server is not validating the data as it comes in then someone could
>> conceivably reproduce the post action of your form and force  
>> invalid data
>> into any field. Javascript is the only way to get instant  
>> feedback, but if
>> you are relying solely on javascript for validation then you can  
>> be assured
>> someone can weasel around it.
>
> You''re missing the point of DRY.  It''s not that actions
are never
> duplicated, but that we only *write* it once, in one place.  If a
> validates_* method could be used to generate both server-side and
> client-side (JavaScript) validation, then it would be a very DRY
> solution.  The validation might be repeated, but we only write the
> validation requirement once.
>
> ~Avdi
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails

Avdi Grimm wrote:
> You''re missing the point of DRY.  It''s not that actions
are never
> duplicated, but that we only *write* it once, in one place.  If a
> validates_* method could be used to generate both server-side and
> client-side (JavaScript) validation, then it would be a very DRY
> solution.  The validation might be repeated, but we only write the
> validation requirement once.
> 
> ~Avdi
I''m with Avdi all the way here.  But, if there isn''t a way to
do that,
I''ve got the AJAX in Action book and will bone up on how to make it 
happen the hard way.

It would be better to have the API support this type of validation 
though.

Hey, maybe after I grow up and become a real Rails developer this will 
become my pet project.  :o)  I''d do it now, but you''d see some
really
fugly code.  lol
> This seems wrong.
Julian, what do you mean?  What seems wrong?

-- 
Posted via http://www.ruby-forum.com/.

On 3/15/06, Julian Leviston <julian@coretech.net.au>
wrote:
> This seems wrong.
In "The Pragmatic Programmer", which introduced the "DRY"
principle, the principle is defined thus:

   Every piece of knowledge must have a single, unambiguous, authoritative
   representation within a system.

Dave & Andy go on to elaborate:

   At the coding level, we often need to have the same information represented
   in different forms.  Maybe we''re writing a client-server
application, using
   different languages on the client and server, and need to represent some
   shared structure on both. [...] Often the answer is to write a
simple filter or
   code generator. Structures in multiple languages can be built from a
   common metadata representation using a simple generator[...] The trick is
   to make the process active: this cannot be a one-time conversion, or
we''re
   back in the position of duplicating data.

In this case, the validates_* declaration is the generator, which
would take an abstract validation specification and translate it into
both server-side (Ruby) and client-side (JavaScript) representations.

~Avdi

If someone does look into implementing this (it would be a very nice
addition), you may want to check out how struts does it.  They were
doing this over 2 years ago.  i.e. generating the server side and
client side code from the same config file.

On 3/16/06, Avdi Grimm <avdi.grimm@gmail.com>
wrote:
> On 3/15/06, Julian Leviston <julian@coretech.net.au> wrote:
> > This seems wrong.
>
> In "The Pragmatic Programmer", which introduced the
"DRY"
> principle, the principle is defined thus:
>
>    Every piece of knowledge must have a single, unambiguous, authoritative
>    representation within a system.
>
> Dave & Andy go on to elaborate:
>
>    At the coding level, we often need to have the same information
represented
>    in different forms.  Maybe we''re writing a client-server
application, using
>    different languages on the client and server, and need to represent some
>    shared structure on both. [...] Often the answer is to write a
> simple filter or
>    code generator. Structures in multiple languages can be built from a
>    common metadata representation using a simple generator[...] The trick
is
>    to make the process active: this cannot be a one-time conversion, or
we''re
>    back in the position of duplicating data.
>
> In this case, the validates_* declaration is the generator, which
> would take an abstract validation specification and translate it into
> both server-side (Ruby) and client-side (JavaScript) representations.
>
> ~Avdi
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

Ben Anderson wrote:
> If someone does look into implementing this (it would be a very nice
> addition), you may want to check out how struts does it.  They were
> doing this over 2 years ago.  i.e. generating the server side and
> client side code from the same config file.
This would be a magnet attracting more web developers, don''t you think?

How would we get a project off the ground to implement this type of 
generation?

-- 
Posted via http://www.ruby-forum.com/.

> How would we get a project off the ground to implement this type of
> generation?
writing code is usually the first step :-)

On 3/16/06, Cody Skidmore <hopefulskeptic@mailinator.com>
wrote:
> Ben Anderson wrote:
> > If someone does look into implementing this (it would be a very nice
> > addition), you may want to check out how struts does it.  They were
> > doing this over 2 years ago.  i.e. generating the server side and
> > client side code from the same config file.
>
> This would be a magnet attracting more web developers, don''t you
think?
>
> How would we get a project off the ground to implement this type of
> generation?
>
My initial reaction is to have the form helpers (select, text_field,
etc.) interrogate the models that they are generating inputs for, and
invoke a Javascript helper library to dynamically build JS
validations.
Getting from that sentence to a crude piece of working code actually
doesn''t sound too difficult.  Maybe I should give it a try today.

Ben Anderson wrote:
>> How would we get a project off the ground to implement this type of
>> generation?
> 
> writing code is usually the first step :-)
Okay Mister Obvious..err, maybe its me that''s Mister Obvious.  :o) 
This
is something I''d need, and if I have to write JS anyway, I''ll
have to
figure out how to setup the project and start running, but I''m trying
to
run before I can walk here.

After I get a clue, I''ll put in some work if anyone wants to join me. 
It is a generator we could definitely use as a community.

Add one more to the pile of to-do''s.

-- 
Posted via http://www.ruby-forum.com/.

I took a quick look at the Rails code (1.0), and it looks like this
approach would work, IF you also patched the validates_* methods so
that they add an annotation to the model about what needs to be
validated.  It looks like currently they just add a filter.

~Avdi

On 3/16/06, Wilson Bilkovich <wilsonb@gmail.com>
wrote:
> On 3/16/06, Cody Skidmore <hopefulskeptic@mailinator.com> wrote:
> > Ben Anderson wrote:
> > > If someone does look into implementing this (it would be a very
nice
> > > addition), you may want to check out how struts does it.  They
were
> > > doing this over 2 years ago.  i.e. generating the server side and
> > > client side code from the same config file.
> >
> > This would be a magnet attracting more web developers, don''t
you think?
> >
> > How would we get a project off the ground to implement this type of
> > generation?
> >
>
> My initial reaction is to have the form helpers (select, text_field,
> etc.) interrogate the models that they are generating inputs for, and
> invoke a Javascript helper library to dynamically build JS
> validations.
> Getting from that sentence to a crude piece of working code actually
> doesn''t sound too difficult.  Maybe I should give it a try today.
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

Wilson Bilkovich wrote:
> On 3/16/06, Cody Skidmore <hopefulskeptic@mailinator.com> wrote:
>>
> My initial reaction is to have the form helpers (select, text_field,
> etc.) interrogate the models that they are generating inputs for, and
> invoke a Javascript helper library to dynamically build JS
> validations.
> Getting from that sentence to a crude piece of working code actually
> doesn''t sound too difficult.  Maybe I should give it a try today.
I won''t know what you are talking about until I finish reading the
Rails
book.

-- 
Posted via http://www.ruby-forum.com/.

On Thu, 16 Mar 2006 19:17:06 +0100, Cody Skidmore wrote:
> How would we get a project off the ground to implement this type of 
> generation?
Typically, for new, highly-desirable Rails functionality like this, three
to six programmers would go off and create their own, vaguely incompatible,
orthogonally incomplete implementations - one or two as a generator, a few
plugins, and at least one engine.  For best effect, they should all be
named similarly.

Jay Levitt

That sounds about right for my impression of the rails community.

Instead of a DRY principle we really should have something like a DRYOO
where its Don''t Repeat Yourself Or Others principle. (or some other
cuter
variation.)

I would really like to see this feature and I could see a lot of people
using it but lets hope its done right instead of the 10 login generators
which 90% are out of date and dead.

Adam



On 3/16/06, Jay Levitt <jay+news@jay.fm> wrote:
>
> On Thu, 16 Mar 2006 19:17:06 +0100, Cody Skidmore wrote:
>
> > How would we get a project off the ground to implement this type of
> > generation?
>
> Typically, for new, highly-desirable Rails functionality like this, three
> to six programmers would go off and create their own, vaguely
> incompatible,
> orthogonally incomplete implementations - one or two as a generator, a few
> plugins, and at least one engine.  For best effect, they should all be
> named similarly.
>
> Jay Levitt
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060316/fc8abafa/attachment.html

Adam.Cooper wrote:
> That sounds about right for my impression of the rails community.
> 
> Instead of a DRY principle we really should have something like a DRYOO
> where its Don''t Repeat Yourself Or Others principle. (or some
other
> cuter
> variation.)
> 
> I would really like to see this feature and I could see a lot of people
> using it but lets hope its done right instead of the 10 login generators
> which 90% are out of date and dead.
> 
> Adam
Getting it organized under one project is kind of what I''m hoping for 
here.  Get the guys who are interested in actually putting together a 
generator or engine or plugin under just one project.  Get them to agree 
on a design, and begin implementation.

I know, that''s just a little too much to ask, but it works better when 
everyone contributes to the same effort.  :o)

Is anyone interested in actually doing this?

-- 
Posted via http://www.ruby-forum.com/.

>  Get the guys who are interested in actually putting together a
>  generator or engine or plugin under just one project.
Can I add "patch" to this list?  It seems like the sort of thing that
might be appropriate in the Rails core.
> Is anyone interested in actually doing this?
Sadly, by the time I bone up on Javascript enough to make myself
useful to this effort, I''m afraid it will be long-solved...

~Avdi

Avdi Grimm wrote:
>>  Get the guys who are interested in actually putting together a
>>  generator or engine or plugin under just one project.
> 
> Can I add "patch" to this list?  It seems like the sort of thing
that
> might be appropriate in the Rails core.
> 
>> Is anyone interested in actually doing this?
> 
> Sadly, by the time I bone up on Javascript enough to make myself
> useful to this effort, I''m afraid it will be long-solved...
> 
> ~Avdi
The AJAX in Action book is about an inch thick.  Not exactly a weekend 
read!  :o)

-- 
Posted via http://www.ruby-forum.com/.

Struts is actually using commons-validator from the Apache Jakarta project...
and I hate
to say it, but I don''t think it''s very dry.

It has an xml configuration file into which you can put your javascript
validations (in
CDATA tags) or it can link to the name of a javascript file in the package
structure
(that''s what the built-in validations do). This javascript is included
into the jsp page
by use a Struts tag (not sure how you include the javascript if you''re
not using struts).

However, these javascript files are not run on the server side... there are
separate java
classes for that. I''ve always thought this isn''t the best
design...  Apache has had the
Rhino javascript engine for years; they could have used that. And now, Java 6 is
going to
introduce script handling (javascript, php, and ruby! I believe). I hope they
get around
to a re-write after that.

Anyway, I agree that having one source for the validation logic would be ideal.

b

Ben Anderson wrote:
> If someone does look into implementing this (it would be a very nice
> addition), you may want to check out how struts does it.  They were
> doing this over 2 years ago.  i.e. generating the server side and
> client side code from the same config file.
> 
> On 3/16/06, Avdi Grimm <avdi.grimm@gmail.com> wrote:
> 
>>On 3/15/06, Julian Leviston <julian@coretech.net.au> wrote:
>>
>>>This seems wrong.
>>
>>In "The Pragmatic Programmer", which introduced the
"DRY"
>>principle, the principle is defined thus:
>>
>>   Every piece of knowledge must have a single, unambiguous,
authoritative
>>   representation within a system.
>>
>>Dave & Andy go on to elaborate:
>>
>>   At the coding level, we often need to have the same information
represented
>>   in different forms.  Maybe we''re writing a client-server
application, using
>>   different languages on the client and server, and need to represent
some
>>   shared structure on both. [...] Often the answer is to write a
>>simple filter or
>>   code generator. Structures in multiple languages can be built from a
>>   common metadata representation using a simple generator[...] The
trick is
>>   to make the process active: this cannot be a one-time conversion, or
we''re
>>   back in the position of duplicating data.
>>
>>In this case, the validates_* declaration is the generator, which
>>would take an abstract validation specification and translate it into
>>both server-side (Ruby) and client-side (JavaScript) representations.
>>
>>~Avdi
>>_______________________________________________
>>Rails mailing list
>>Rails@lists.rubyonrails.org
>>http://lists.rubyonrails.org/mailman/listinfo/rails
>>
> 
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails

Take also look at known attempts: http://dev.rubyonrails/ticket/861 and
http://www.schuerig.de/michael/boilerplate/

Ben Munat wrote:
> Anyway, I agree that having one source for the validation logic would be 
> ideal.
> 
> 
Well, SQL allows to define fairly good amount of constraints over table
attribute values - I think it''s a good place for single source of
validation logic.

Here''s list of possible SQL constraint and some thoughts about
complexity of Ruby(or JS) code to perform validations before sending
data  to server:

  1. NOT NULL  - trivial

  2. STANDARD TYPE (numeric, string, boolean, date, time, etc.) -
validation as check if presentation format allows value to be correctly
type-casted can be quite easily performed.

  3. VALUE LIMITS (sizes of varchar, numeric) - trivial

  4. CHECK CONSTRAINTS - are the most complex, as  can include calls to
standard   functions (length(), current_date, trim, etc.), operators(+,
-, /, * etc.),  comparisons( <, >, ==, !=, between etc.), set inclusion
(in, not in),  regular expression matches (=~, !~),  logical operations
(OR, AND, NOT), nested expressions, and refer to SEVERAL columns at once
(say, ''CHECK ( gross_price >= net_price )'' ) - and
that''s only brief
overview :)))

Ideal solution would be to declare ALL constraints in SQL DDL and when
retrieving model metadata a code generator would inject appropriate
methods to model class, thus deriving validations directly from
constraints and produce JS code for client-side validations.

-- 
Posted via http://www.ruby-forum.com/.

This is bit off topic, but...

I''m not that crazy about pushing almost any kind of logic onto the data
store.  IMO, rules should be delegated to the middle tier.  Any logic 
you put into the data store has to be replicated if you switch to a 
different database engine.

At a previous job, we supported three or more database engines at a time 
on the same middle tier.  As long as we kept rules in the middle tier, 
supporting a different database engine was almost trivial.

Our earlier architecture contained stored procedure, constraints, 
triggers, etc, and we were completely bound to one db vender as a 
result.

-- 
Posted via http://www.ruby-forum.com/.

Oh man, as a dba, I can''t help but reply :)

There are some things you simply can''t do efficiently unless you do it
on the DB.  I think too often people get afraid of being forced to stick
with one DB, when in reality you probably wont switch anyway.

Since the Db is actually interpreting the TSQL code being thrown at it
and making its best guess about how to use indexes, etc. stored
procedures are particularly useful for forcing a compiler to work one
way or another.  In addition, with large tables, or queries that require
complex logic, you simply cannot do it on the client side with any
efficiency.

I feel better :)

-B




PS: I love this example.. Most people aren''t aware that the join order
can effect the query time.

1) Take this query.
Select * from large_table lt join small_table st on lt.id=ct.id

2) On most RBDMS systems you can make it more efficient by simply
switching the join order.
Select * from small_table st join large_table lt on lt.id=ct.id

Well, :o) I''m not going to send us into a fracas, especially
considering
I''m talking to a dba here ;o) and you''re thoughts on the
matter are
influenced by being a dba.

We''ll just have to agree as gentlemen to disagree.  lol

I haven''t see much I couldn''t do efficiently on the middle
tier.  As
stated in my previous posting, we supported three or more database 
engines simultaneously.  Having a bunch of processing done in stored 
procedures just doesn''t work for us as a result.

Could you give examples of what is done more efficiently on the database 
server?  We didn''t run into complex queries as you describe.  We just 
stuck with the KISS principle and things worked fine.

-- 
Posted via http://www.ruby-forum.com/.

Anytime you''re working with large result sets the database is going to
be more efficient. Using the middle tier makes a lot of sense in some
cases, but putting that data into code is in some ways throwing away the
very thing DBs are good at -- handling large sets of data. For instance,
an app I''ve worked on needed to calculate sums of previously paid
quantities (along with a bunch of other stuff), for a few thousand
records at a time. Doing it row by row took more than 10 minutes (on a
dual xeon with 6gb of ram). By switching the calculations to be based on
the results of a join, it went down to 10-15 seconds. I think this is a
decent illustration of a case where taking advantage of the data layer
was really the right thing to do, rather than building and tearing down
50,000 individual database hits (even with connection pooling) from the
middle tier.

Every app is different, and so there''s never going to be a rule of
middle tier vs data tier.

DISCLAIMER: I''m a RoR newbie who''s been lurking on the list.
If I said
something that doesn''t hold true for RoR, I apologize in advance, and
please ignore me :)

-----Original Message-----
From: rails-bounces@lists.rubyonrails.org
[mailto:rails-bounces@lists.rubyonrails.org] On Behalf Of Cody Skidmore
Sent: Friday, March 17, 2006 1:58 PM
To: rails@lists.rubyonrails.org
Subject: [Rails] RE: Re: DRY principle form validations

Well, :o) I''m not going to send us into a fracas, especially
considering

I''m talking to a dba here ;o) and you''re thoughts on the
matter are
influenced by being a dba.

We''ll just have to agree as gentlemen to disagree.  lol

I haven''t see much I couldn''t do efficiently on the middle
tier.  As
stated in my previous posting, we supported three or more database 
engines simultaneously.  Having a bunch of processing done in stored 
procedures just doesn''t work for us as a result.

Could you give examples of what is done more efficiently on the database

server?  We didn''t run into complex queries as you describe.  We just 
stuck with the KISS principle and things worked fine.

-- 
Posted via http://www.ruby-forum.com/.
_______________________________________________
Rails mailing list
Rails@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails

You''ve got a valid point here making it a good example.  The way we 
handled this challenge though, was to issue a batch process performing a 
bulk transaction on the database server.  We didn''t construct thousands
of objects and perform summations on them.

On your other point, how many web apps have you seen where you grab 
large chuncks of data and send it to the client?  Wouldn''t you paginate
it instead?

-- 
Posted via http://www.ruby-forum.com/.

This procedure wasn''t for showing data to the user, it was to create a
new payment entry. Right now that procedure is a little over 700 lines
of SQL. The result though is just an ID.

I''d agree though that most of the time pagination is a good answer. I
have seen clients though that specifically didn''t want pagination. Or
at
least didn''t THINK they wanted it :)

-----Original Message-----
From: rails-bounces@lists.rubyonrails.org
[mailto:rails-bounces@lists.rubyonrails.org] On Behalf Of Cody Skidmore
Sent: Friday, March 17, 2006 2:36 PM
To: rails@lists.rubyonrails.org
Subject: [Rails] RE: RE: Re: DRY principle form validations

You''ve got a valid point here making it a good example.  The way we 
handled this challenge though, was to issue a batch process performing a

bulk transaction on the database server.  We didn''t construct thousands
of objects and perform summations on them.

On your other point, how many web apps have you seen where you grab 
large chuncks of data and send it to the client?  Wouldn''t you paginate
it instead?

-- 
Posted via http://www.ruby-forum.com/.
_______________________________________________
Rails mailing list
Rails@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails

Hi Peter.  For some reason you seem familiar.  Do you hang out on Java 
or Delphi forums at all?

-- 
Posted via http://www.ruby-forum.com/.