Forum: Ruby on Rails Lack of support of Stored Procedures is a Show Stopper

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
E938f911ab8f5f261a5150baa0b654f3?d=identicon&s=25 intrader (Guest)
on 2006-01-09 23:45
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
Ad7805c9fcc1f13efc6ed11251a6c4d2?d=identicon&s=25 Alex Young (Guest)
on 2006-01-10 01:23
(Received via mailing list)
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
E938f911ab8f5f261a5150baa0b654f3?d=identicon&s=25 intrader (Guest)
on 2006-01-10 01:33
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
Ad7805c9fcc1f13efc6ed11251a6c4d2?d=identicon&s=25 Alex Young (Guest)
on 2006-01-10 02:14
(Received via mailing list)
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.
3203ed0e608d3bfae1e31282e629ffa2?d=identicon&s=25 Peter Fitzgibbons (Guest)
on 2006-01-10 16:13
(Received via mailing list)
On 1/9/06, Alex Young <alex@blackkettle.org> wrote:
> > And yes I don't
> 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.

--
This topic is locked and can not be replied to.