Rails - Jan 2006 - Lack of support of Stored Procedures is a Show Stopper

In my opinion most mature/complex client/server or n-tier applications 
using SQL Server, Oracle, or MySQL, use stored procedures.
Without support (except by use of the execute method) for Stored 
Procedures, Ruby on Rails or MonoRail is a Show Stopper. We are unable 
to effectively use Ruby On Rails as all access to the db is using Stored 
Procedures.
This does not mean that we are unable to use ORM. In fact, if we were to 
be able to consider a Store Procedure results set as a View, we can 
easily analyze the view (or DataSet) returned as a first step in 
creating/updating the objects and their classes.
As to ActiveRecord, and ActiveRecord is not a proper representation of a 
Busines Object. I think the patten is simplistic and although useful, it 
is not sufficient. In my opinion we should have Busines Object 
Collections and Business Objects. To create a Business Object Collection 
we sould need to interate through the ActiveRecords.

I''d appreciate any comments, pleas to
intrader@aol.com

Thanks


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

intrader wrote:
> In my opinion most mature/complex client/server or n-tier applications 
> using SQL Server, Oracle, or MySQL, use stored procedures.
That''s one way to skin the cat, certainly.  In my opinion most complex 
n-tier applications should be broken into tiny pieces (with great 
prejudice, ideally) that don''t need them.  Then again, my opinion 
doesn''t count for much.  I''m not a bank.  Neither are most of
Rails'' users.
> Without support (except by use of the execute method) for Stored 
> Procedures, Ruby on Rails or MonoRail is a Show Stopper. We are unable 
> to effectively use Ruby On Rails as all access to the db is using Stored 
> Procedures.
Then I guess you''re not going to be using Rails :-)  Truth be told, I 
can''t see it being that hard to write an AR equivalent to (as you point
out) use a returned dataset as the basis for an access object.
> As to ActiveRecord, and ActiveRecord is not a proper representation of a 
> Busines Object. I think the patten is simplistic and although useful, it 
> is not sufficient. 
What do you think is missing?
> In my opinion we should have Busines Object 
> Collections and Business Objects. To create a Business Object Collection 
> we sould need to interate through the ActiveRecords.
Not sure I follow here.  What would you be able to do with a business 
object collection that you couldn''t do with a class method in AR? 
What''s missing?  And what''s stopping you from implementing an 
ActiveRecordCollection that does it, then showing us why it''s better?

-- 
Alex

Alex Young wrote:
> intrader wrote:
>> In my opinion most mature/complex client/server or n-tier applications 
>> using SQL Server, Oracle, or MySQL, use stored procedures.
> That''s one way to skin the cat, certainly.  In my opinion most
complex
> n-tier applications should be broken into tiny pieces (with great
> prejudice, ideally) that don''t need them.  Then again, my opinion
> doesn''t count for much.  I''m not a bank.  Neither are
most of Rails''
> users.
> 
Yes, many ways to skin the cat - in our case, application programmers 
are restricted from directly accessing the db. Everything is thru Stored 
Procedures.
>> Without support (except by use of the execute method) for Stored 
>> Procedures, Ruby on Rails or MonoRail is a Show Stopper. We are unable 
>> to effectively use Ruby On Rails as all access to the db is using
Stored
>> Procedures.
> Then I guess you''re not going to be using Rails :-)  Truth be
told, I
> can''t see it being that hard to write an AR equivalent to (as you
point
> out) use a returned dataset as the basis for an access object.
> 
I am impressed with Rails clean MVC vs. the somwhat muddled .NET way.
>> As to ActiveRecord, and ActiveRecord is not a proper representation of
a
>> Busines Object. I think the patten is simplistic and although useful,
it
>> is not sufficient. 
> What do you think is missing?
> 
>> In my opinion we should have Busines Object 
>> Collections and Business Objects. To create a Business Object
Collection
>> we sould need to interate through the ActiveRecords.
> Not sure I follow here.  What would you be able to do with a business
> object collection that you couldn''t do with a class method in AR?
> What''s missing?  And what''s stopping you from
implementing an
> ActiveRecordCollection that does it, then showing us why it''s
better?
> 
I sm missing something, as I am not a Rails programmer (yet). What I see 
is that your model classes inherit from ActiveRecord. And yes I don''t 
see any problems in implementing an ActiveRecordCollection.  I just 
don''t know Rails.
> --
> Alex

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

intrader wrote:
> I sm missing something, as I am not a Rails programmer (yet). What I see 
> is that your model classes inherit from ActiveRecord. 
It''s important to realise that inheriting from ActiveRecord
isn''t
actually required.  It''s just the most common case.  Besides which,
Ruby
supports a flexible enough notion of multiple inheritance to allow an 
enormously capable business object model to be built around the 
structure you''re given.
> And yes I don''t 
> see any problems in implementing an ActiveRecordCollection.  I just 
> don''t know Rails.
I''m still unclear as to what such an object might actually *do*... 
What
would its methods be?  What would it sound like when it quacked?  I can 
dream up a couple of possible ideas, but I don''t know if it''s
what
you''re thinking of.

-- 
Alex

On 1/9/06, Alex Young <alex@blackkettle.org>
wrote:
>
> intrader wrote:
> > I sm missing something, as I am not a Rails programmer (yet). What I
see
> > is that your model classes inherit from ActiveRecord.
> It''s important to realise that inheriting from ActiveRecord
isn''t
> actually required.  It''s just the most common case.  Besides
which, Ruby
> supports a flexible enough notion of multiple inheritance to allow an
> enormously capable business object model to be built around the
> structure you''re given.
>
> > And yes I don''t
> > see any problems in implementing an ActiveRecordCollection.  I just
> > don''t know Rails.
> I''m still unclear as to what such an object might actually *do*...
What
> would its methods be?  What would it sound like when it quacked?  I can
> dream up a couple of possible ideas, but I don''t know if
it''s what
> you''re thinking of.
>
> --
> Alex
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
I encourage you to investigate overriding the basic CRUD operations within
AR to utilize direct SQL calls in their stead.  You will run into an
organizational issue in that introducing SP''s into the call stack
introduces
an additional indirection in naming the operations.  What I mean is... SQL
is standard.. .there is only one way to say "SELECT FROM".  OTOH, your
SP
could be named ANYTHING ("sp_something_get",
"sp_something_read",
"whatever_you_like_to_call_it").  And in my experience, you are very
lucky
if you have a DB Admin team that has absolutely used the same naming
convention across the several hundred procedures in your database.

Rails can do this.  You *can* alter the system to perform this trick.  I
would be very interested in your results.

Good Luck.

--
------------------------------
me in you, you in me
   - the primal empathic mirror in all of us.
------------------------------
Peter Fitzgibbons
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060110/f6c1be7c/attachment.html