On May 26, 11:48 am, GregD <[email protected]> wrote:
> Jeremy,
>
> A little background and maybe you can guide me.
>
> The shop that I'm at right now does no TDD or BDD. There are no
> automated testing either. I'm going to slowly bring in Testing to the
> development process. My first goal is to use Sequel to execute stored
> procs and make sure results are correct. Results are more than a
> result set coming back from the stored proc call. They are using a
> lot of stored procs to do a lot of business workflow, etc. My thought
> is to use rspec and call the stored procs then make sure results are
> correct. Again results will be more than a select on a called stored
> proc. I may have to do many different Sequel::Dataset calls to test
> if the stored proc did what it was suppose to do with the given args
> passed into it.
Honestly, Sequel's built in support for stored procedures isn't very
extensive. For example, it doesn't handle IN/OUT parameters, and it
is only supported on MySQL and JDBC. If your database is a heavy user
of stored procedures, Sequel built in support may not be enough.
That's not saying you shouldn't use Sequel at all. But it may be best
to access the database connection directly to run the stored
procedures:
DB.synchronize do |conn|
conn.execute_stored_procedure(...)
end
Here conn would be your JDBC connection, so you'd run whatever JDBC
methods you want for the stored procedure.
> It sounds to me from what you are saying is to create models for the
> results returned from the stored proc. I'd like to avoid this since
> there are soooo many stored procs and keep my models as "real" to the
> db schema as possible. But, if you think it is better to create
> models for each result set coming back, then I try going down that
> path.
I'm not saying you should create models, I'm just saying Sequel's
support is based in the dataset level so that you have the ability
to. If the stored procedures are returning rows that you have an
existing model for, use that model, but don't create models specific
to each stored procedure unless it will help your application.
> Also, this is not a web client server app. It is java swing client
> server apps, java communication apps (TCP/IP and UDP sockets) for IPC/
> RPC , and File processing apps for batch processing.
It's nice to see Sequel used in non-web apps. How's the experience
been so far?
Jeremy
--
You received this message because you are subscribed to the Google Groups
"sequel-talk" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sequel-talk?hl=en.
