Re: ZPsycoPGDA: How to contribute

Adding documentation
Adding unit tests

> These would be very welcome.
Ok, I will provide these.
>> Implementing minor changes regarding my post above in db.py and Pool.py
> I haven't found the details you refer to in the article...
Hum... I speak too fast, I have not described them yet.
I am writing another blog for this regarding my recent changes made on
ZcxOracleDA
>
>> Maybe putting in comments Pool.py as it is not really required, except for
>> its implementation of the *close* function which close all database
>> connections and may be very usefull: default implementation only close
>> database connection of the DB object of the thread executing the method (and
>> not for all threads DB objects) - but I still have to check this before.
> For any contribution you'd like to provide, you can fork the
> ZPsycopgDA project on github, which is currently at the state of
> psycopg 2.4.6. Provide the contributions you want into external
> branches and I'll merge them back. As I've previously stated, the Zope
> adapter may well benefit of a release cycle independent from psycopg.
Yes, this is an important change and may be not useful.
I will document Pool.py first explaning what I have understood, what can
be changed and suggest minor changes/bug corrections.
But it may not be required regarding Zope connection management
described in my blog, except for closing all threads connections at one
time.

I will fork your project.
Thanks.
>> Also, I will be pleased to implement "bind variables" management in a
>> similar way that the implementation I've recently worked on for ZcxoracleDA
>> and that I will submit now to this project.
> It sounds like prepared statements: they could be more generically
> useful in psycopg too, not only in ZPsycopgDA. I have an experiment in
> [1] but that's definitely not the only way to implement the same
> concept (an useful one would be auto-preparation with LRU cache). I'd
> like to first ask the DB-SIG if there is any idea about standardizing
> a stored procedures interface.
>
> [1] http://initd.org/psycopg/articles/2012/10/01/prepared-statements-psycopg/
Yes I had read it, and had a look at your cursor with prepared statement
class https://gist.github.com/3797445 in december.
As you say it: there are a lot of ways to implement prepared statements
with cursors.
And the best solution may depend  of your goal and configuration.
> Do you have an article or code showing what have you done for the
> oracle adapter about bind variables?
Yes, I have the code available just now.
The documentation is in progress and should be ready tomorrow I hope.
You can have a look at:
https://github.com/MordicusEtCubitus/ZcxOracleDA that I've just committed.

The idea I have worked on is: "create a File system ZSQL method, like
.zsql in all ways, except that file extension is .zora (to continue
allowing classic usage of .zsql) and which generates SQL statements
using bind variables"

I still have to add unit testing and documentation to this new version
of ZcxOracleDA and then I will come back to describe it in deep.

The fact is that in this ZcxOracleDA version, a .zsql using this query:

SELECT * from EMPLOYEE
<dtml-sqlgroup WHERE>
<dtml-sqltest ID column="EMPLOYEE_ID" type="int">
</dtml-sqlgroup>

Will generate this SQL code when parameter ID=123456:

SELECT * FROM EMPLOYEE WHERE EMPLOYEE_ID=123456

If you rename the .zsql into .zora, the generated SQL code is:

SELECT * FROM EMPLOYEE WHERE EMPLOYEE_ID=:ID

and a hash table containing {'ID':123456} is sent to the DB.query()
method with this code.
The statement is prepared the first time, then following execution do
not require execution plan to be calculated again.
Query execution is about x6 on my computer.


With kind regards,

Gaël,

> Cheers,
>
> -- Daniele
>
>


--
Gaël Pegliasco, chef de projet
MAKINA CORPUS - www.makina-corpus.com
29 Quai de Versailles FR-44000 Nantes
T : +33 (0) 2 51 79 80 84 / M-GSM: +33 (0)6 41 69 16 09