Electronics & Programming

develissimo

Open Source electronics development and programming

  • You are not logged in.
  • Root
  • » PHP
  • » [PHP-DEV] Re: [PDO] Re: [PHP-DEV] [PATCH] New PDO methods for PostgreSQL driver [RSS Feed]

#1 June 13, 2010 20:10:46

Stanley S.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Re: [PDO] Re: [PHP-DEV] [PATCH] New PDO methods for PostgreSQL driver


On Sat, Jun 12, 2010 at 4:54 AM, Ilia Alshanetsky <i***@*rohost.org> wrote:
> The concerns you raised about custom methods specific to database drivers
> were not reflective of the PDO's intent as was clarified by Wez and myself.
>
> The code that was introduced was specific to PostgreSQL, the common
> functionality was introduced in a way that allows each driver to implement.


Yet the rest of the copyFrom, copyTo, etc.. could have ben generic as
well. I specifically stated that this could be done at the driver
level for FreeTDS using the BCP extensions and/or using "BULK INSERT
". Yet now this is a specific pgsql*** interface that cannot be
abstracted for other drivers OR implemented at the driver level. Now
if I want a MSSQL / Sybase dump/load method, I need to preface it with
dblibCopyFrom, dblibCopyTo.

IMHO, every function should be a generic named interface to the driver
or statement level and then throw a "not implemented" if the driver
does not support it. This will allow for abstraction at a higher level
and give the driver developers an opportunity to implement it. It will
also give PDO users a more structured way to deal with unsupported
methods with try/catch.

I know I am a noob to the PDO development process, however I have used
OO for quite awhile and I have never seen it DB abstractions
implemented like this.

>
> On Sat, Jun 12, 2010 at 12:24 PM, Pierre Joye <pierre.***@*mail.com> wrote:
>
>> hi Ilia,
>>
>> So you basically say that the worries and wishes raised here are
>> simply irrelevant and at the end of the day you decide what PDO can or
>> cannot be?
>>
>> I'm very disappointed by these two commits. I don't think it is the
>> way we should develop PDO and it is clear that I'm not the only one to
>> think that. As it is trunk, I won't battle too much to revert it but
>> be sure that is not something I will let in for any of the upcoming
>> releases as it is clearly bad design.
>>
>> Cheers,
>> --
>> Pierre
>>
>> On Thu, Jun 10, 2010 at 2:12 PM, Ilia Alshanetsky <i***@*rohost.org>
>> wrote:
>> > I've added the transaction code as a generic method inTransaction(), by
>> > default it'll just use in_txn internal parameter, but allows the driver
>> to
>> > extend this (as was done in PostgreSQL) and provide a detailed status
>> code.
>> >
>> > On Wed, May 26, 2010 at 1:11 PM, Denis Gasparin
>> > <denis.gaspa***@*distar.com>wrote:
>> >
>> >>
>> >> I attached to this mail a new version of the patch both in unified and
>> >> single file format.
>> >>
>> >> I attached the unit tests for all the new methods too.
>> >> They are three files: one for pgsqlIsInTransaction(), one for
>> >> pgsqlCopyFrom*  methods and one for pgsqlCopyTo* methods.
>> >>
>> >> I did a typo writing the documentation in my first mail. The typo is
>> about
>> >> the $fields parameter.
>> >> It is actually a string (not an array) with field names separated by
>> comma.
>> >>
>> >> If needed, I can write also documentation in a more suitable format for
>> php
>> >> web site.
>> >>
>> >> The updated documentation of the methods follows.
>> >>
>> >> Any feedback is appreciated.
>> >>
>> >> Thank you in advance,
>> >> Denis
>> >>
>> >> pgsqlIsInTransaction()
>> >>
>> >>    It uses the native Postgresql functions to check transaction status.
>> >>    It returns one of the following status codes:
>> >>        * PDO:GSQL_TRANSACTION_IDLE: connection in idle status
>> >>       * PDO:GSQL_TRANSACTION_ACTIVE: connection is executing a command
>> >>       * PDO:GSQL_TRANSACTION_INTRANS: connection is idle in a valid
>> >> transaction block
>> >>       * PDO:GSQL_TRANSACTION_INERROR: connection is idle, in a failed
>> >> transaction block
>> >>       * PDO:GSQL_TRANSACTION_UNKNOWN: connection is in a bad status
>> >>
>> >>
>> >>
>> >> pgsqlCopyFromArray($table,Array $data,$delimiter,$null, Array $fields)
>> >>
>> >>    It uses the native Postgresql copy construct to append $data to
>> $table.
>> >>    It returns boolean.
>> >>    Parameters:
>> >>       * (mandatory) $table: table to append data to
>> >>       * (mandatory) $data: Array of rows with data in table field order
>> >>                           (or as specified in the $fields array). Fields
>> >> must be separated by $delimiter or by
>> >>                           postgresql standard \t)
>> >>       * $delimiter: alternative delimiter to use in place of the
>> standard
>> >> postgres delimiter ("\t")
>> >>       * $null: alternative string to use as null value. Default is "\N"
>> >>        * $fields: string with table fields that are specified in $data
>> >> parameter. Fields are separated by comma
>> >>
>> >>
>> >>
>> >> pgsqlCopyFromFile($table,$filename,$delimiter,$null,$fields)
>> >>
>> >>    It uses the native Postgresql copy construct to append $filename
>> >> contents to $table.
>> >>    It returns boolean.
>> >>    Parameters:
>> >>       * (mandatory) $table: table to append data to.
>> >>       * (mandatory) $filename: file with contents to append to $table.
>> See
>> >> Postgresql documentation for the format.
>> >>       * $delimiter: alternative delimiter to use in place of the
>> standard
>> >> postgres delimiter ("\t")
>> >>       * $null: alternative string to use as null value. Default is "\N"
>> >>        * $fields: string with table fields that are specified in
>> $filename
>> >> file. Fields are separated by comma
>> >>
>> >> pgsqlCopyToArray($table,$delimiter,$null,$fields)
>> >>
>> >>    It uses the native Postgresql copy construct to retrieve $table
>> contents
>> >> and store them to an array.
>> >>    It returns an array of rows or false in case of problems.
>> >>    The format of the rows into the array is indicated in the $delimiter,
>> >> $null and $fields parameters.
>> >>    Parameters:
>> >>       * (mandatory) $table: table to retrieve data from.
>> >>       * $delimiter: alternative delimiter to use in place of the
>> standard
>> >> postgres delimiter ("\t")
>> >>       * $null: alternative string to use as null value. Default is "\N"
>> >>        * $fields: string with table fields to include in the row of the
>> >> array. Fields are separated by comma
>> >>
>> >>
>> >> pgsqlCopyToFile($table,$filename,$delimiter,$null,$fields)
>> >>
>> >>
>> >>    It uses the native Postgresql copy construct to retrieve $table
>> contents
>> >> and store them into a file.
>> >>    It returns boolean.
>> >>    The format of the rows stored into the file is indicated in the
>> >> $delimiter, $null and $fields parameters.
>> >>    Parameters:
>> >>       * (mandatory) $table: table to retrieve data from.
>> >>       * (mandatory) $filename: file where to store the contents of the
>> >> table
>> >>       * $delimiter: alternative delimiter to use in place of the
>> standard
>> >> postgres delimiter ("\t")
>> >>       * $null: alternative string to use as null value. Default is "\N"
>> >>        * $fields: string with table fields to include in the row of the
>> >> array. Fields are separated by comma
>> >>
>> >>
>> >> ----- Messaggio originale -----
>> >> > Da: "Ilia Alshanetsky" <i***@*rohost.org>
>> >> > A: "Denis Gasparin" <denis.gaspa***@*distar.com>
>> >> > Cc: intern***@*ists.php.net
>> >> > Inviato: Martedì, 25 maggio 2010 18:40:09
>> >> > Oggetto: Re: New PDO methods for PostgreSQL driver
>> >>
>> >> > Good reason, I'll review the patch in the next day or two.
>> >> >
>> >> >
>> >> > On Mon, May 24, 2010 at 5:55 PM, Denis Gasparin <
>> >> > denis.gaspa***@*distar.com > wrote:
>> >> >
>> >> >
>> >> >
>> >> > The copy to/from sql statements accept both as main parameter a
>> >> > filename or stdout/stdin respectively.
>> >> >
>> >> > The filename represents a file in the database filesystem (apache/php
>> >> > and postgresql must reside on the same machine or share the file via
>> >> > shared filesystem). I quote from the postgresql manual:
>> >> >
>> >> > <<<
>> >> > COPY with a file name instructs the PostgreSQL server to directly read
>> >> > from or write to a file. The file must be accessible to the server and
>> >> > the name must be specified from the viewpoint of the (database)
>> >> > server.
>> >> > >>>
>> >> >
>> >> > Because of this "limitation", if you'd like to load a csv file into
>> >> > pgsql via copy command, you must before copy into a shared folder and
>> >> > the issue the copy from filename command.
>> >> > Using the methods added to PDO, you can do it directly from the
>> >> > webserver.
>> >> >
>> >> > About copying to/from stdin and stdout, PostgreSQL enters a particular
>> >> > status after a copy stdin/stdout command has been issued via sql.
>> >> > These status codes are PGRES_COPY_OUT and PGRES_COPY_IN. When in this
>> >> > status, the only way to interact with the database server is via
>> >> > PQgetCopyData and PQputCopyData.
>> >> >
>> >> > There are not PDO methods or functions that implements these functions
>> >> > and there is no way to share the connection between PDO driver and old
>> >> > pgsql drivers.
>> >> >
>> >> > These are the relevant PostgreSQL man pages:
>> >> >
>> >> >http://www.postgresql.org/docs/8.2/interactive/libpq-copy..html>> >> >http://www.postgresql.org/docs/8.2/interactive/sql-copy.html>> >> >
>> >> > Denis
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > > Denis could you elaborate on what makes use of the COPY code via Sql
>> >> > > behave differently then a PHP method call?
>> >> > >
>> >> > > Ilia Alshanetsky
>> >> > > CIO/CSO Centah Inc.
>> >> > >
>> >> > > On 2010-05-24, at 15:45, Denis Gasparin <
>> denis.gaspa***@*distar.com
>> >> > > >
>> >> > > wrote:
>> >> > >
>> >> > > >
>> >> > > > I'll provide the patches in a single file as soon as possible..
>> >> > > >
>> >> > > > Actually all the methods are wrappers against the native
>> >> > > > PostgreSQL commands (connection status, copy to/from).
>> >> > > >
>> >> > > > I needed to develop them as methods because it is not possible to
>> >> > > > get the same results with a sql statement (in particular for
>> >> > > > connection status).
>> >> > > >
>> >> > > > It was not possible also for COPY TO/FROM because of the way
>> >> > > > PostgreSQL handle them ( special functions were developed also for
>> >> > > > the old pgsql driver).
>> >> > > >
>> >> > > > We are currently using them in production and we needed them in
>> >> > > > order to avoid additional connections to database (one with the
>> >> > > > old driver and one with PDO).
>> >> > > >
>> >> > > > Denis
>> >> > > >
>> >> > > >
>> >> > > > ----- Messaggio originale -----
>> >> > > >> Da: "Ilia Alshanetsky" < i***@*rohost.org >
>> >> > > >> A: "Denis Gasparin" < denis.gaspa***@*distar.com >
>> >> > > >> Cc: intern***@*ists.php.net
>> >> > > >> Inviato: Lunedì, 24 maggio 2010 19:54:46
>> >> > > >> Oggetto: Re: New PDO methods for PostgreSQL
>> >> > > >> driver
>> >> > > >
>> >> > > >> Denis,
>> >> > > >>
>> >> > > >>
>> >> > > >> Could you merge the patches into a single for easier code review.
>> >> > > >> Also, the copy to/from file seems like it would just be a wrapper
>> >> > > >> against the native COPY PostgreSQL command, is there really a
>> >> > > >> need to provide a method for it?
>> >> > > >>
>> >> > > >>
>> >> > > >> On Mon, May 24, 2010 at 4:57 AM, Denis Gasparin <
>> >> > > >> denis.gaspa***@*distar.com > wrote:
>> >> > > >>
>> >> > > >>
>> >> > > >> Hi.
>> >> > > >>
>> >> > > >> I developed some patches for PDO/Postgresql driver in order to
>> >> > > >> add some useful methods that were available in the original pgsql
>> >> > > >> driver.
>> >> > > >>
>> >> > > >> The attached patches apply on 5.3.2 and svn 5.3.x.
>> >> > > >> If needed, i have patches also for 5.2.x.
>> >> > > >>
>> >> > > >> Please comment and tell me improvements or tips.
>> >> > > >>
>> >> > > >> Thank you in advance,
>> >> > > >>
>> >> > > >> Denis Gasparin
>> >> > > >>
>> >> > > >> Documentation of the added methods follows:
>> >> > > >>
>> >> > > >> pgsqlIsInTransaction()
>> >> > > >>
>> >> > > >> It uses the native Postgresql functions to check transaction
>> >> > > >> status..
>> >> > > >> It returns one of the following status codes:
>> >> > > >> * PDO::PGSQL_TRANSACTION_IDLE: connection in idle status
>> >> > > >> * PDO::PGSQL_TRANSACTION_ACTIVE: connection is executing a
>> >> > > >> command * PDO::PGSQL_TRANSACTION_INTRANS: connection is idle in a
>> >> > > >> valid transaction block
>> >> > > >> * PDO::PGSQL_TRANSACTION_INERROR: connection is idle, in a failed
>> >> > > >> transaction block
>> >> > > >> * PDO::PGSQL_TRANSACTION_UNKNOWN: connection is in a bad status
>> >> > > >>
>> >> > > >>
>> >> > > >>
>> >> > > >> pgsqlCopyFromArray($table,Array $data,$delimiter,$null, Array
>> >> > > >> $fields)
>> >> > > >>
>> >> > > >> It uses the native Postgresql copy construct to append $data to
>> >> > > >> $table. It returns boolean.
>> >> > > >> Parameters: * (mandatory) $table: table to append data to
>> >> > > >> * (mandatory) $data: Array of rows with data in table field order
>> >> > > >> (or as specified in the $fields array). Fields must be separated
>> >> > > >> by $delimiter or by
>> >> > > >> postgresql standard \t)
>> >> > > >> * $delimiter: alternative delimiter to use in place of the
>> >> > > >> standard postgres delimiter ("\t")
>> >> > > >> * $null: alternative string to use as null value. Default is "\N"
>> >> > > >> * $fields: array with table fields that are specified in $data
>> >> > > >> parameter
>> >> > > >>
>> >> > > >>
>> >> > > >>
>> >> > > >> pgsqlCopyFromFile($table,$filename,$delimiter,$null,$fields)
>> >> > > >>
>> >> > > >> It uses the native Postgresql copy construct to append $filename
>> >> > > >> contents to $table.
>> >> > > >> It returns boolean.
>> >> > > >> Parameters: * (mandatory) $table: table to append data to.
>> >> > > >> * (mandatory) $filename: file with contents to append to $table.
>> >> > > >> See Postgresql documentation for the format.
>> >> > > >> * $delimiter: alternative delimiter to use in place of the
>> >> > > >> standard postgres delimiter ("\t")
>> >> > > >> * $null: alternative string to use as null value. Default is "\N"
>> >> > > >> * $fields: array with table fields that are specified in
>> >> > > >> $filename file
>> >> > > >>
>> >> > > >> pgsqlCopyToArray($table,$delimiter,$null,$fields)
>> >> > > >>
>> >> > > >> It uses the native Postgresql copy construct to retrieve $table
>> >> > > >> contents and store them to an array.
>> >> > > >> It returns an array of rows or false in case of problems.
>> >> > > >> The format of the rows into the array is indicated in the
>> >> > > >> $delimiter, $null and $fields parameters.
>> >> > > >> Parameters: * (mandatory) $table: table to retrieve data from..
>> >> > > >> * $delimiter: alternative delimiter to use in place of the
>> >> > > >> standard postgres delimiter ("\t")
>> >> > > >> * $null: alternative string to use as null value. Default is "\N"
>> >> > > >> * $fields: array with table fields to include in the row of the
>> >> > > >> array.
>> >> > > >>
>> >> > > >>
>> >> > > >> pgsqlCopyToFile($table,$filename,$delimiter,$null,$fields)
>> >> > > >>
>> >> > > >>
>> >> > > >> It uses the native Postgresql copy construct to retrieve $table
>> >> > > >> contents and store them into a file.
>> >> > > >> It returns boolean.
>> >> > > >> The format of the rows stored into the file is indicated in the
>> >> > > >> $delimiter, $null and $fields parameters.
>> >> > > >> Parameters: * (mandatory) $table: table to retrieve data from..
>> >> > > >> * (mandatory) $filename: file where to store the contents of the
>> >> > > >> table * $delimiter: alternative delimiter to use in place of the
>> >> > > >> standard postgres delimiter ("\t")
>> >> > > >> * $null: alternative string to use as null value. Default is "\N"
>> >> > > >> * $fields: array with table fields to include in the row of the
>> >> > > >> array.
>> >> > > >>
>> >> > > >> -- PHP Internals - PHP Runtime Development Mailing List
>> >> > > >> To unsubscribe, visit:http://www.php.net/unsub.php>> >>
>> >
>>
>>
>>
>> --
>> Pierre
>>
>> @pierrejoye |http://blog.thepimp.net|http://www.libgd.org>>
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#2 June 14, 2010 04:39:38

Stanley S.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Re: [PDO] Re: [PHP-DEV] [PATCH] New PDO methods for PostgreSQL driver


On Sun, Jun 13, 2010 at 3:52 PM, Jared Williams
<jared.willia***@*tlworld.com> wrote:
>
>
>> -----Original Message-----
>> From: Stanley Sufficool
>> Sent: 13 June 2010 20:10
>> To: Ilia Alshanetsky
>> Cc: Pierre Joye; Denis Gasparin; Matteo Beccati;
>> intern***@*ists.php.net; pdo
>> Subject: Re: Re: Re: New
>> PDO methods for PostgreSQL driver
>>
>> On Sat, Jun 12, 2010 at 4:54 AM, Ilia Alshanetsky
>> <i***@*rohost.org> wrote:
>> > The concerns you raised about custom methods specific to database
>> > drivers were not reflective of the PDO's intent as was
>> clarified by Wez and myself.
>> >
>> > The code that was introduced was specific to PostgreSQL, the
> common
>> > functionality was introduced in a way that allows each
>> driver to implement.
>>
>>
>> Yet the rest of the copyFrom, copyTo, etc.. could have ben
>> generic as well. I specifically stated that this could be
>> done at the driver level for FreeTDS using the BCP extensions
>> and/or using "BULK INSERT ". Yet now this is a specific
>> pgsql*** interface that cannot be abstracted for other
>> drivers OR implemented at the driver level. Now if I want a
>> MSSQL / Sybase dump/load method, I need to preface it with
>> dblibCopyFrom, dblibCopyTo.
>>
>> IMHO, every function should be a generic named interface to
>> the driver or statement level and then throw a "not
>> implemented" if the driver does not support it. This will
>> allow for abstraction at a higher level and give the driver
>> developers an opportunity to implement it. It will also give
>> PDO users a more structured way to deal with unsupported
>> methods with try/catch.
>>
>> I know I am a noob to the PDO development process, however I
>> have used OO for quite awhile and I have never seen it DB
>> abstractions implemented like this.
>
>
> But a complete nonsense for a PDO driver maintainer.
> If adds one function to a driver, then you have to had add an function
> to all the rest.

The interface would start out as "unsupported" / NULL function pointer
in all other drivers and PDO should throw an unsupported as is does
for all the other non-implemented driver interfaces.

>
> A generic copyFrom or copyTo method should only be added when there is
> enough PDO drivers that behave in exactly the same manner, and to do
> that, you needed specific implementations to test and compare with.
>
> If the dblib methods can't behave the same as the postgres methods,
> then clearly they shouldn't be named the same.

Yes, DBLIB behaves the same as pgsql in that it performs the copy in a
transaction state and also has it's data visible from the server
perspective. So would SQLite 2.x "COPY", IBM "EXPORT", MySQL "SELECT
... INTO OUTFILE", etc...

>
> Jared
>
>
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#3 June 14, 2010 04:47:07

Stanley S.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Re: [PDO] Re: [PHP-DEV] [PATCH] New PDO methods for PostgreSQL driver


On Sun, Jun 13, 2010 at 8:38 PM, Stanley Sufficool <ssuffic***@*mail.com> wrote:
> On Sun, Jun 13, 2010 at 3:52 PM, Jared Williams
> <jared.willia***@*tlworld.com> wrote:
>>
>>
>>> -----Original Message-----
>>> From: Stanley Sufficool
>>> Sent: 13 June 2010 20:10
>>> To: Ilia Alshanetsky
>>> Cc: Pierre Joye; Denis Gasparin; Matteo Beccati;
>>> intern***@*ists.php.net; pdo
>>> Subject: Re: Re: Re: New
>>> PDO methods for PostgreSQL driver
>>>
>>> On Sat, Jun 12, 2010 at 4:54 AM, Ilia Alshanetsky
>>> <i***@*rohost.org> wrote:
>>> > The concerns you raised about custom methods specific to database
>>> > drivers were not reflective of the PDO's intent as was
>>> clarified by Wez and myself.
>>> >
>>> > The code that was introduced was specific to PostgreSQL, the
>> common
>>> > functionality was introduced in a way that allows each
>>> driver to implement.
>>>
>>>
>>> Yet the rest of the copyFrom, copyTo, etc.. could have ben
>>> generic as well. I specifically stated that this could be
>>> done at the driver level for FreeTDS using the BCP extensions
>>> and/or using "BULK INSERT ". Yet now this is a specific
>>> pgsql*** interface that cannot be abstracted for other
>>> drivers OR implemented at the driver level. Now if I want a
>>> MSSQL / Sybase dump/load method, I need to preface it with
>>> dblibCopyFrom, dblibCopyTo.
>>>
>>> IMHO, every function should be a generic named interface to
>>> the driver or statement level and then throw a "not
>>> implemented" if the driver does not support it. This will
>>> allow for abstraction at a higher level and give the driver
>>> developers an opportunity to implement it. It will also give
>>> PDO users a more structured way to deal with unsupported
>>> methods with try/catch.
>>>
>>> I know I am a noob to the PDO development process, however I
>>> have used OO for quite awhile and I have never seen it DB
>>> abstractions implemented like this.
>>
>>
>> But a complete nonsense for a PDO driver maintainer.
>> If adds one function to a driver, then you have to had add an function
>> to all the rest.
>
> The interface would start out as "unsupported" / NULL function pointer
> in all other drivers and PDO should throw an unsupported as is does
> for all the other non-implemented driver interfaces.
>
>>
>> A generic copyFrom or copyTo method should only be added when there is
>> enough PDO drivers that behave in exactly the same manner, and to do
>> that, you needed specific implementations to test and compare with.
>>
>> If the dblib methods can't behave the same as the postgres methods,
>> then clearly they shouldn't be named the same.
>
> Yes, DBLIB behaves the same as pgsql in that it performs the copy in a
> transaction state and also has it's data visible from the server
> perspective. So would SQLite 2.x "COPY", IBM "EXPORT", MySQL "SELECT
> ... INTO OUTFILE", etc...

Errr... correction, BCP is client side data.

>
>>
>> Jared
>>
>>
>>
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

  • Root
  • » PHP
  • » [PHP-DEV] Re: [PDO] Re: [PHP-DEV] [PATCH] New PDO methods for PostgreSQL driver [RSS Feed]

Board footer

Moderator control

Enjoy the 20th of October
PoweredBy

The Forums are managed by develissimo stuff members, if you find any issues or misplaced content please help us to fix it. Thank you! Tell us via Contact Options
Leave a Message
Welcome to Develissimo Live Support