Skip to content

Conversation

@flash-gordon
Copy link
Contributor

Hi Raimonds!

At my work I have a lot of pipelined functions that generates small sets of data. Everyone of them take parameters (e.g. user_id) and returns a list of rows (see my spec for example). It it very convenient API between our Oracle DB application and RoR interface. So I plan to create a gem that will alllow to set a pipelined function as standard ActiveRecord table. I think it's better than reinventing the wheel.

First of all I need a list of arguments and return type description of function so I took your gem and change code of procedure calls. I have to refactored it a little bit :)

And sorry for my English :)

My changes:

.gitignore

I use RubyMine so it creates it's .idea work directory.

package.rb

Create several class method for object searching. Just for clarity
Package object now can return procedures or types by “find” method. If
there are FIND procedure then last will be called (still can use
find synonym).

pipelined_function.rb

Inherited from Procedure class (but I think both of them should be
inherited from Subprogram). Three finders and custom “exec” method.
That's all.

pipelined_function_call.rb

Custom SQL building and data fetching.

procedure.rb

Find method rewritten. All queries now use ALL_PROCEDURES (with filter
by PIPELINED field).

procedure_call.rb

Code moved to subprogram_call.rb. Only SQL construction and execution
was left (and DBMS_OUTPUT as well for a while).

subprogram_call.rb

Just all good stuff from ProcedureCall but refactored a bit. I tried to
dry it.

ruby_plsql.rb

Add new files for requiring.

spec_helper.rb

I have to insert DATABASE_USE_TNS_NAMES environment variable for correct
testing. I always use TNS_NAMES and SSH tunnels to connect to Oracle. So
I must leave host and port empty.

-- .gitignore
I use RubyMine so it creates it's .idea work directory.

-- package.rb
Create several class method for object searching. Just for clarity
Package object now can return procedures or types by “find” method. If
there are FIND procedure then last will be called (still can use
__find__ synonym).

-- pipelined_function.rb
Inherited from Procedure class (but I think both of them should be
inherited from Subprogram). Three finders and custom “exec” method.
That's all.

-- pipelined_function_call.rb
Custom SQL building and data fetching.

-- procedure.rb
Find method rewritten. All queries now use ALL_PROCEDURES (with filter
by PIPELINED field).

-- procedure_call.rb
Code moved to subprogram_call.rb. Only SQL construction and execution
was left (and DBMS_OUTPUT as well for a while).

-- subprogram_call.rb
Just all good stuff from ProcedureCall but refactored a bit. I tried to
dry it.

-- ruby_plsql.rb
Add new files for requiring.

-- spec_helper.rb
I have to insert DATABASE_USE_TNS_NAMES environment variable for correct
testing. I always use TNS_NAMES and SSH tunnels to connect to Oracle. So
I must leave host and port empty.
@rsim
Copy link
Owner

rsim commented Jun 13, 2012

Thanks for this proposal and changes but I need to find time to review it :)

One thing that I noticed is usage of find method, e.g. plsql.test_package.find in tests. find could be quite common name of PL/SQL procedure in a package and due to this explicit method definition we might not be able to access it anymore. Therefore it would be better to use some Ruby specific method names which cannot overlap with PL/SQL procedure names. I thought that maybe instead of plsql.test_package.find('some_procedure_name) we could use plsql.test_package['some_procedure_name'] and rename find method to [] method.

@flash-gordon
Copy link
Contributor Author

Good idea. I'll do it.
But I already redefine find as singleton method to use method_missing if it overlaps with oracle object in a package (see package contructor).
Anyway using [] is better solution.

Also added pipelined function support to Schema class
@flash-gordon
Copy link
Contributor Author

[] method added.

Anton Gorodishenin and others added 2 commits April 5, 2013 21:36
@jgebal
Copy link
Contributor

jgebal commented May 31, 2015

Looks like large piece of nice work.
@flash-gordon Can you merge the most recent ruby-plsql so the pull request is still mergeable?

Due to the large rework done, it's not easy to review it, but it might be worth a second try.

@flash-gordon
Copy link
Contributor Author

Oh. It will take a while :) If I remember it correctly one large part of the PR is consist of trivial code movement and the other one is refactoring of procedure-call related code in a more OOP-ish style. I understand that it's difficult to read and accept all at once but back in those days my time was limited. Sorry about that :)
I'll deal with this PR next weekend.

@jgebal
Copy link
Contributor

jgebal commented Jun 1, 2015

Do you think it would be better to split it into several pieces of rework?
This way it will be easier to focus on refactoring vs. new features.
Thanks for coming back on this.

@flash-gordon
Copy link
Contributor Author

Yep, sure.

@stale
Copy link

stale bot commented Jan 13, 2018

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the wontfix label Jan 13, 2018
@stale stale bot closed this Jan 20, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants