Re: Integration of Psycopg with XTA - Mailing list psycopg
From | Christian Ferrari |
---|---|
Subject | Re: Integration of Psycopg with XTA |
Date | |
Msg-id | 634068058.7859603.1538930530793@mail.yahoo.com Whole thread Raw |
In response to | Re: Integration of Psycopg with XTA (Federico Di Gregorio <fog@dndg.it>) |
Responses |
Re: Integration of Psycopg with XTA
|
List | psycopg |
Hi Federico,
I've just tryed out commit https://github.com/fogzot/psycopg2/commit/81addddaee2c690e925bb8f381e7bcb02ca97687 : get_native_connection() is in the interface, but unfortunately it seems to work differently than the old _raw_pgconn.
Here's my code snippet:
pgconn = rm1.get_native_connection()
#pgconn = rm1._raw_pgconn xar1 = PostgresqlXaResource(pgconn, "PostgreSQL", "dbname=testdb")
using get_native_connection(), I catch an error from XTA, the PGconn pointer is null.
I have reversed back to commit https://github.com/fogzot/psycopg2/commit/ccae5cae34051d6640ec6cbce6d9313778c509d3 : _raw_pgconn works as before.
Here's the code snippet:
#pgconn = rm1.get_native_connection()
pgconn = rm1._raw_pgconn
xar1 = PostgresqlXaResource(pgconn, "PostgreSQL", "dbname=testdb")
pgconn = rm1._raw_pgconn
xar1 = PostgresqlXaResource(pgconn, "PostgreSQL", "dbname=testdb")
It works fine.
Should "get_native_connection()" used differently than "_raw_pgconn" ? What type of data are necessary to investigate the issue?
Thanks in advance
Kind Regards
Ch.F.
-------------------------------------------------------------
Good design can't stop bad implementation
Good design can't stop bad implementation
Il domenica 7 ottobre 2018, 13:56:49 CEST, Federico Di Gregorio <fog@dndg.it> ha scritto:
On 10/05/2018 06:02 PM, Christian Ferrari wrote:
> In a previous mail I stated something like "the name of the method
> doesn't matter"...
> ... after better thinking I realized a decent name might be better than
> other ones...
> Let me say:
>
> get_native_conn()
> get_native_connection()
>
> might be better than "get_/something/_pgconn" because the same type of
> method could be useful for other databases in the future...
> More or less all the databases use a "native connection", only
> PostgreSQL uses "PGconn connection".
After some more checking I discovered that it isn't possible to
"invalidate" a PyCapsule so there is no way to tell if the pointer
inside it is still a valid libpq connection.
The current code (feel free to pull) adds a new method
get_native_connection()
that raise an exception if called on a closed connection. I better like
a method here because it gives the idea that you need to call it every
time you want a Capsule to pass to the target C API.
I also added some docs and a dumb test.
https://github.com/fogzot/psycopg2/tree/feature-expose-pgconn
@Daniele, if Christian reports no problems I'll merge this later for 2.8.
Io non sono romantica. La candelina sul tavolo mi vede e si spegne.
-- sisterconfusion
> In a previous mail I stated something like "the name of the method
> doesn't matter"...
> ... after better thinking I realized a decent name might be better than
> other ones...
> Let me say:
>
> get_native_conn()
> get_native_connection()
>
> might be better than "get_/something/_pgconn" because the same type of
> method could be useful for other databases in the future...
> More or less all the databases use a "native connection", only
> PostgreSQL uses "PGconn connection".
After some more checking I discovered that it isn't possible to
"invalidate" a PyCapsule so there is no way to tell if the pointer
inside it is still a valid libpq connection.
The current code (feel free to pull) adds a new method
get_native_connection()
that raise an exception if called on a closed connection. I better like
a method here because it gives the idea that you need to call it every
time you want a Capsule to pass to the target C API.
I also added some docs and a dumb test.
https://github.com/fogzot/psycopg2/tree/feature-expose-pgconn
@Daniele, if Christian reports no problems I'll merge this later for 2.8.
Io non sono romantica. La candelina sul tavolo mi vede e si spegne.
-- sisterconfusion