I finally got back to this and I still can not get it to work. I'm going to try some real basic stored proc stuff like a proc that just selects a literal as a column_name and see if I can get any type of success.
> 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 Well, from java where we call the procs we don't use any extensive stuff. we just expect a resultset. Many are just an ErrMsg column to be evaluated. I tried the above code and the execute_stored_procedure is an unknown method. Was I suppose to write that method or use a Sybase java library class method? > It's nice to see Sequel used in non-web apps. How's the experience > been so far? Well, I use sequel at home for web and did 1 minor java swing app using monkeybars and rawr gems. The jotbot guys and their blogs a few years back turned me onto Sequel, since they were using it for standalone java swing apps. I struggled with extracting AR from Rails grip to use in a java app and Sequel was much easier to use in the java app and much easier to put into Rails. But, I use it with the DBs it supports. I'm thinking most of my issues here at work are with Sybase not being a supported DB and trying it out. Also, the heavy use of stored procs, which always I try to avoid. Rant: I just luv my NEW job. Oh, why can't Cincinnati area companies start to use the kewl kids' toys/tools like ruby, rails, git, rsped, cucumber, etc. Later, GregD On May 26, 3:19 pm, Jeremy Evans <[email protected]> wrote: > 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.
