Closed n8falke closed 1 month ago
Thanks for your clear description of what you would like to see. It seems quite reasonable to me!
I made the suggested change and added some tests. The aslist() method now simply uses the generator instead of duplicating the code! If you are able to build from source you can verify that it works for you, too.
Thank you for the very fast reply and change.
Yes, it works perfect with for, *-unpacking, collection-constructors, map(...).
You are right, the proposed function was nearly a copy of aslist() and your solution is much cleaner code.
Not important and probably the wrong place to ask: Do you perhaps know how I can change the returned type to int/decimal from DbObject with "TABLE OF NUMBER"?
There is no way to do so, currently. The driver looks at the metadata and returns either int or float depending on whether the metadata says only integers are allowed or not. If you want the ability to return decimals you will need to log another enhancement request.
Thank you for that hint. Controlling the type by definition works for me.
Took me while to understand the mechanism:
Column or collection defined with type | Data-value | Python resulting type |
---|---|---|
NUMBER or TABLE OF NUMBER | 42 | int |
NUMBER or TABLE OF NUMBER | 123.4 | float |
NUMBER(9) or TABLE OF NUMBER(9) | 42 | int |
NUMBER(15,4) or TABLE OF NUMBER(15,4) | 42 | float |
NUMBER(15,4) or TABLE OF NUMBER(15,4) | 123.4 | float |
for all | NULL | NoneType |
This was included in version 2.2.0 which was just released.
Allowing the usage of DbObject directly in example for-loops, map() or set()-constructor without aslist() to list conversion would simplify usage of from queries returned collections.
Example implementation:
Example usage with PL/SQL:
Example with SELECT:
Prepare DB:
Python source:
With table data a use case could be: