mroddy's ideas...
Mark Harrison
-------- Original Message --------
Subject: RE: [cx-oracle-users] help me pick a name!
Date: Thu, 22 May 2008 13:21:56 -0400
From: Mark Roddy <mro...@seas.upenn.edu>
To: 'Mark Harrison' <m...@pixar.com>
References: <4828CFFF...@pixar.com> <01ee01c8b48b$8a5f14c0$2840829e@dublin> <4832782E...@pixar.com> <005b01c8ba98$432c6f40$1c0e829e@dublin> <48330C34...@pixar.com>
Mark,
Below are some ideas I had after using orapig for a little bit. Most of
them are pretty simple, and I could generate a patch for in a day or two.
If you let me know a yes/no/maybe with comments I can throw together the
ideas you like.
1) Prompt for password: Allow users to be prompted for a password in such a
way that it is not echoed to the screen so that they do not need to enter it
at the command line if they do not wish their password to be displayed.
2) Export all packages for a specified user: In addition to specifying
packages by name, also allow them to be specified by user. The packages for
that user would then be looked up, and then proceed as if they were entered
at the command line
3) Document function arguments in generated doc strings: If there isn't any
documentation supplied for a function/procedure in a package's source, then
write the information that is known, data types of arguments, if they are
in/out, return type, etc.
4) Handling of functions that have arguments with or return
unknown/unsupported data types: I ran against a package from our dev group
that returns a record type and it resulted in an error as that type is not
in the 'typemap'. I'm not really sure what the default behavior should be
in this case. I was thinking something like produce the function but have
it raise an error, or produce the code for the function but commented out.
I'd want your input before making any changes on this.
5) Script that runs all tests: I noticed a few issues with tests.
keyword.test.py imports pixardb. I'm assuming this is an internal wrapper
around cx_Oracle you use. I changed this to cx_Oracle relatively easily,
though I did have to add a command line argument so that I could supply a
connection string. I also thought it would be good if there was a single
script that could be run that ran all the tests and reported their outcome.
Also, I work with pyunit quite a bit, and I could convert these tests to
unit tests quite easily if you were interested.
6) Handling of Overloaded Functions: A number of the packages I use have
overloaded functions/procedures. This presents an issue as Python doesn't
support this. I'm not really sure what the best way would be to deal with
this. I saw that currently a python method is created for each version
which results in the last method being the one that is used as it redefines
the method implementation of the previous ones. I spent some time trying to
think of ways to work around this, but never came up with anything that I
was satisfied with so I don't have any suggestions of alternative
approaches. I just wanted to note that this could be an 'issue' for some
people.
-----Original Message-----
From: Mark Harrison [mailto:m...@pixar.com]
Sent: Tuesday, May 20, 2008 1:37 PM
To: Mark Roddy; Bjorn Leffler
Subject: Re: [cx-oracle-users] help me pick a name!
Mark Roddy wrote:
> Hey,
> I pulled down the source code and had a look. I ran into a syntax error,
> but that's because I'm using Python 2.3 at work. I filled a case on the
> Google code site with a patch. No issues on the Python side after I
applied
> the patch.
ah, great. and I was feeling sorry for myself being stuck on 2.4 :-)
>
> I am running into trouble at the point when pulling the procedure names
> down. The query in Trans.getprocedures() is not working against my local
> Oracle XE (10g) install. I didn't file a case on this as I'm assuming
it's
> really just a problem between different versions of Oracle.
I think the user might have to have a data dictionary role. Bjorn, do
you recall which role that is?
> I check through
> the documentation and couldn't find what version of Oracle you have tested
> against. Did I miss this?
Oh, good catch... 10.2.
>
> I do have a few features in mind as well. If you're interested I can run
> them by you, and drop patches for those you'd like.
yes, that would be great!
Thanks!
Mark Roddy
Mark Roddy wrote:
> Mark,
> Below are some ideas I had after using orapig for a little bit. Most
> of them are pretty simple, and I could generate a patch for in a day or two.
> If you let me know a yes/no/maybe with comments I can throw together
> the ideas you like.
>
>
> 1) Prompt for password: Allow users to be prompted for a password in
> such a way that it is not echoed to the screen so that they do not
> need to enter it at the command line if they do not wish their password to be displayed.
connection string of "scott" or "scott@orcl" it will know that it
needs to prompt?
Or is it better to have some flag to say to prompt for the password?
>
> 2) Export all packages for a specified user: In addition to specifying
> packages by name, also allow them to be specified by user. The
> packages for that user would then be looked up, and then proceed as if
> they were entered at the command line
then we can generate all packages by specifying '%' ?
>
> 3) Document function arguments in generated doc strings: If there
> isn't any documentation supplied for a function/procedure in a
> package's source, then write the information that is known, data types
> of arguments, if they are in/out, return type, etc.
some place to get help strings for all of those.
> 4) Handling of functions that have arguments with or return
> unknown/unsupported data types: I ran against a package from our dev
> group that returns a record type and it resulted in an error as that
> type is not in the 'typemap'. I'm not really sure what the default
> behavior should be in this case. I was thinking something like
> produce the function but have it raise an error, or produce the code for the function but commented out.
> I'd want your input before making any changes on this.
would be neat if we could return a list which contains the elements in
the record.
But for now, I think generating a function that raises an exception is
pretty reasonable behavior.
> 5) Script that runs all tests: I noticed a few issues with tests.
> keyword.test.py imports pixardb. I'm assuming this is an internal
> wrapper around cx_Oracle you use. I changed this to cx_Oracle
> relatively easily, though I did have to add a command line argument so
> that I could supply a connection string. I also thought it would be
> good if there was a single script that could be run that ran all the tests and reported their outcome.
> Also, I work with pyunit quite a bit, and I could convert these tests
> to unit tests quite easily if you were interested.
facilities like pyunit, so that is really helpful.
I was thinking to create a default "orapig/tiger" account here, so
that docs, etc, can have a consistent demo account.
> 6) Handling of Overloaded Functions: A number of the packages I use
> have overloaded functions/procedures. This presents an issue as
> Python doesn't support this. I'm not really sure what the best way
> would be to deal with this. I saw that currently a python method is
> created for each version which results in the last method being the
> one that is used as it redefines the method implementation of the
> previous ones. I spent some time trying to think of ways to work
> around this, but never came up with anything that I was satisfied with
> so I don't have any suggestions of alternative approaches. I just
> wanted to note that this could be an 'issue' for some people.
unexplored territory for me. I'll think about this a bit, perhaps
somehow encoding the parm information in the name, something like
def foo_which_takes_number_number(n1, n2):
def foo_which_takes_number_varchar2(a,b):
or some suitably terser version of that???
Great work, this is going to be a lot of fun...
Mark
Mark Roddy
>
> Posting Mark Harrison's response to email above.
>
> Mark Roddy wrote:
> > Mark,
> > Below are some ideas I had after using orapig for a little bit. Most
> > of them are pretty simple, and I could generate a patch for in a day or two.
> > If you let me know a yes/no/maybe with comments I can throw together
> > the ideas you like.
> >
> >
> > 1) Prompt for password: Allow users to be prompted for a password in
> > such a way that it is not echoed to the screen so that they do not
> > need to enter it at the command line if they do not wish their password to be displayed.
>
> good idea. Should it do this automatically, so if it sees a
> connection string of "scott" or "scott@orcl" it will know that it
> needs to prompt?
> Or is it better to have some flag to say to prompt for the password?
user. It is the way sqlplus works. It could be an issue though if a
user has a blank password. Does anyone know if Oracle allows empty
passwords? I wouldn't advise anyone to do so, but I don't think its
my place to tell someone they can't.
> >
> > 2) Export all packages for a specified user: In addition to specifying
> > packages by name, also allow them to be specified by user. The
> > packages for that user would then be looked up, and then proceed as if
> > they were entered at the command line
>
> good idea. How about if we select the package names with 'like', so
> then we can generate all packages by specifying '%' ?
Sounds good. I think I might tackle this first.
>
> >
> > 3) Document function arguments in generated doc strings: If there
> > isn't any documentation supplied for a function/procedure in a
> > package's source, then write the information that is known, data types
> > of arguments, if they are in/out, return type, etc.
>
> yes, that's especially good for the system packages. I wish there was
> some place to get help strings for all of those.
I haven't dove into a large number of the system packages, but I have
seen a few that have parameter documentation in the source for the
package specification (though obviously the body is encrypted). Note
that there will need some translation as a few of the system packages
have characters in the names that are illegal in python, the dollar
sign ($) specificly.
> > 4) Handling of functions that have arguments with or return
> > unknown/unsupported data types: I ran against a package from our dev
> > group that returns a record type and it resulted in an error as that
> > type is not in the 'typemap'. I'm not really sure what the default
> > behavior should be in this case. I was thinking something like
> > produce the function but have it raise an error, or produce the code for the function but commented out.
> > I'd want your input before making any changes on this.
>
> that's a good question. I'm not sure what callfunc does for this. It
> would be neat if we could return a list which contains the elements in
> the record.
>
> But for now, I think generating a function that raises an exception is
> pretty reasonable behavior.
I actually had to do some research on this. The function that I
refered to is only called by other packages and not by python source
so I had never tried calling it from cx_Oracle. It appears as though
cx_Oracle doesn't support PL\SQL records as a return type, though I
would like to confirm whether or not this is correct before
blacklisting it as an exceptable data type. When I tackle this I'll
change the generated source to raise an exception rather then calling
cx_Oracle. Would 'TypeError' be acceptable?
> > 5) Script that runs all tests: I noticed a few issues with tests.
> > keyword.test.py imports pixardb. I'm assuming this is an internal
> > wrapper around cx_Oracle you use. I changed this to cx_Oracle
> > relatively easily, though I did have to add a command line argument so
> > that I could supply a connection string. I also thought it would be
> > good if there was a single script that could be run that ran all the tests and reported their outcome.
> > Also, I work with pyunit quite a bit, and I could convert these tests
> > to unit tests quite easily if you were interested.
>
> that is great. I'm not super-familiar with all of these nice python
> facilities like pyunit, so that is really helpful.
>
> I was thinking to create a default "orapig/tiger" account here, so
> that docs, etc, can have a consistent demo account.
This would actually entail quite a few changes to the testing code, so
I'll enumerate them in a seperate email.
> > 6) Handling of Overloaded Functions: A number of the packages I use
> > have overloaded functions/procedures. This presents an issue as
> > Python doesn't support this. I'm not really sure what the best way
> > would be to deal with this. I saw that currently a python method is
> > created for each version which results in the last method being the
> > one that is used as it redefines the method implementation of the
> > previous ones. I spent some time trying to think of ways to work
> > around this, but never came up with anything that I was satisfied with
> > so I don't have any suggestions of alternative approaches. I just
> > wanted to note that this could be an 'issue' for some people.
>
> good point. I'm a bit of a PL/SQL beginner so a lot of this is
> unexplored territory for me. I'll think about this a bit, perhaps
> somehow encoding the parm information in the name, something like
>
> def foo_which_takes_number_number(n1, n2):
> def foo_which_takes_number_varchar2(a,b):
>
> or some suitably terser version of that???
This is actually something that held me up before as I couldn't come
up with a scheme that I felt was satisfactory. Here are the options
that I come up with:
1) Use the 'overload' column from the user_arguments table as suffex
to the name of the python function.
def foo1(...)
def foo2(...)
This could get confusing if someone already has numeric suffexes in
their function names.
2) Add a lightweight syntax that can be used in the package/function
comments to define names to be used when generating python code. This
would be more powerful, but can sometimes result in comments that are
way to verbose. I've experienced this using epydoc for python.
3) Nothing. Dump all the versions of the function and let the user
sort out the generated code. This would be the easiest, but could
frustrate users if the python function the end up calling is not the
one they intended.
> Great work, this is going to be a lot of fun...
>
> Mark
Yes it is! I hope to have a patch or two ready sometime next week.
-Mark
>
> >
>