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. 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. 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. Eventually, I'd like to use cucumber or something for the integration testing. First I'd like to get unit testing to work. Any thoughts or ideas? From anyone? Thanks, GregD On May 26, 12:24 pm, Jeremy Evans <[email protected]> wrote: > On May 26, 8:27 am, GregD <[email protected]> wrote: > > > Okay, > > > This made me look at it closer. I was passing in a hash instead of an > > array for the args. Now, it seems hung. I'll let you know it I get > > success or not once I figure out why it did not return. > > > Do I need to set :sproc => true if this is a procedure vs a function? > > > Thanks, > > > GregD > > You don't need to set :sproc => true. Actually, you are using the > wrong interface. While call_sproc is a Database method, you should be > using the call_sproc Dataset method: > > DB.dataset.call_sproc(:select, :name, arg1, arg2, arg3, ...) > DB.dataset.call_sproc(:insert, :other_name, arg1, arg2, arg3, ...) > > The reason it is a dataset method instead of a database method is that > you can have stored procedures operate like a dataset, in that they > can do inserts, updates, deletes, and selects. Making it a dataset > method allows you to set up a row proc so that you can have stored > procedure calls that automatically yield model objects. > > 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.
