Issue 16 in orapig: overloaded function

[codesite...@google.com]

Status: New
Owner: ----

New issue 16 by vladislav.nazarenko: overloaded function
http://code.google.com/p/orapig/issues/detail?id=16

What steps will reproduce the problem?
1. Just let it generate for the package with some overloaded functions

What is the expected output? What do you see instead?
The generation fails

What version of the product are you using? On what operating system?
orapig 1.1 on Linux

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings

[codesite...@google.com]

Comment #1 on issue 16 by MarkRoddy: overloaded function
http://code.google.com/p/orapig/issues/detail?id=16

Wanted to note: we discussed this briefly before on the mailing list though
I don't
think we ever reached a conclusion of how to deal with the issue:
http://groups.google.com/group/orapig-dev/browse_thread/thread/8a49a163e95b3089

[Mark Harrison]

codesite...@google.com wrote:
>
> Comment #1 on issue 16 by MarkRoddy: overloaded function
> http://code.google.com/p/orapig/issues/detail?id=16
>
> Wanted to note: we discussed this briefly before on the mailing list though
> I don't
> think we ever reached a conclusion of how to deal with the issue:
> http://groups.google.com/group/orapig-dev/browse_thread/thread/8a49a163e95b3089

yes, I've created a simple test case for it now, attached...

What's the best way to handle this? Can we keep the single function
name and cleverly decode the parms? Or use a p(**args) and let
cx_Oracle and python figure it out?

Mark

create or replace
package overload1
------------------------------------------------------------------------
--+ test overloaded procedure signatures
--+
--+ test script:
--+
--+ create table overload_counts(x_varchar2 number, x_number number);
--+
--+ delete from overload_counts;
--+ insert into overload_counts values(0,0);
--+ select * from overload_counts;
--+ exec overload1.p(12);
--+ select * from overload_counts;
--+ exec overload1.p('hello');
--+ select * from overload_counts;
--+
------------------------------------------------------------------------
as
--------------------------------------------------------------------
--+ p(number) -- param is number
--------------------------------------------------------------------
procedure p(x in number);

--------------------------------------------------------------------
--+ p(varchar2) -- param is varchar2
--------------------------------------------------------------------
procedure p(x in varchar2);

end overload1;

create or replace
package body overload1
as
--------------------------------------------------------------------
procedure p(x in number)
is
begin
update overload_counts set x_number=x_number+1;
end;

--------------------------------------------------------------------
procedure p(x in varchar2)
is
begin
update overload_counts set x_varchar2=x_varchar2+1;
end;

end overload1;

[Mark Harrison]

Mark Harrison wrote:
> codesite...@google.com wrote:
>> Comment #1 on issue 16 by MarkRoddy: overloaded function
>> http://code.google.com/p/orapig/issues/detail?id=16
>>
>> Wanted to note: we discussed this briefly before on the mailing list though
>> I don't
>> think we ever reached a conclusion of how to deal with the issue:
>> http://groups.google.com/group/orapig-dev/browse_thread/thread/8a49a163e95b3089
>
> yes, I've created a simple test case for it now, attached...
>
>
> What's the best way to handle this? Can we keep the single function
> name and cleverly decode the parms? Or use a p(**args) and let
> cx_Oracle and python figure it out?

wow, at least for the single-parm case cx_Oracle will figure
it out. Most Excellent Anthony!

I deleted all the functions except for this one, and it works
like a charm. I'm going to try some variable lengths of
arguments and try p(**args).

If that works, then this will be a much easier problem... just
figuring out how to carry the doc strings forward for each
of the overloaded parms.

#------------------------------------------------------
def p(self,x):

"""
p(varchar2) -- param is varchar2
"""

result = self.curs.callproc('OVERLOAD1.P',[x])
if self.autocommit:
conn.commit()
return result

and ran this test with this results:

curs.execute('select * from overload_counts'); print curs.fetchall()
x.p(12)
curs.execute('select * from overload_counts'); print curs.fetchall()
x.p('hello')
curs.execute('select * from overload_counts'); print curs.fetchall()

conn.close()

[(0, 0)]
[(0, 1)]
[(1, 1)]

[Mark Harrison]

Mark Harrison wrote:
> Mark Harrison wrote:
>> codesite...@google.com wrote:
>>> Comment #1 on issue 16 by MarkRoddy: overloaded function
>>> http://code.google.com/p/orapig/issues/detail?id=16
>>>
>>> Wanted to note: we discussed this briefly before on the mailing list though
>>> I don't
>>> think we ever reached a conclusion of how to deal with the issue:
>>> http://groups.google.com/group/orapig-dev/browse_thread/thread/8a49a163e95b3089
>> yes, I've created a simple test case for it now, attached...
>>
>>
>> What's the best way to handle this? Can we keep the single function
>> name and cleverly decode the parms? Or use a p(**args) and let
>> cx_Oracle and python figure it out?
>
>
> wow, at least for the single-parm case cx_Oracle will figure
> it out. Most Excellent Anthony!
>
>
>
>
> I deleted all the functions except for this one, and it works
> like a charm. I'm going to try some variable lengths of
> arguments and try p(**args).
>
>
> If that works, then this will be a much easier problem... just
> figuring out how to carry the doc strings forward for each
> of the overloaded parms.

and it does, hooray!

x.p(12) ; show(curs)
x.p('hello') ; show(curs)
x.p(15,'hello') ; show(curs)

[(0, 0)]
[(0, 1)]
[(1, 1)]

[(2, 2)]

here's the modified function.

#------------------------------------------------------
def p(self,*args):

result = self.curs.callproc('OVERLOAD1.P',args)