PDO Oracle driver

2015-04-23 17:02 GMT+03:00 Pierre Joye pierre.php@gmail.com:

On Apr 23, 2015 8:45 PM, "Arvids Godjuks" arvids.godjuks@gmail.com
wrote:

My view is that this really needs a good discussion and regardless of
the
desicions made - resource allocation to move it forward.
Whatever the intent was originally for the PDO and and regardless of
what
the docs say about it, as Christoph has linked and quoted, the reality
is
PDO is everywhere. Doctrine? Based on PDO. Yii 1/2 ActiveRecord? PDO.
Laravel's Eloquent ? PDO again. You get the picture.

Not being in core is an issue with PDO. Sqlsrv is in pecl, maintained,
and support both "native" and PDO.

I do not think it's a "in core" vs "in pecl" issue at all. It's the fact
that that it is data objects and it was new back in the day - the adoption
of it was lightning fast. It was easy to make an abstraction over it, it
fit to major patterns, like AR, like a glove.
Besides, installing DB modules for PHP under ubuntu is done by hand -
it's not built into the "php5" package.

Just like many other. Not being in core brings actually more flexibility to
the devs

On Fri, Apr 24, 2015 at 1:16 PM, Arvids Godjuks
arvids.godjuks@gmail.com wrote:

2015-04-24 4:42 GMT+03:00 Benjamin Eberlei kontakt@beberlei.de:

On Thu, Apr 23, 2015 at 3:45 PM, Arvids Godjuks arvids.godjuks@gmail.com
wrote:

PDO is everywhere. Doctrine? Based on PDO.

You can use mysqli, oci8 or sqlsrv for example without problems in
Doctrine.

Exposing some of the internal api of PDO as php functions (SQL Parser) I
would bet it is possible to reimplement PDO in PHP code using mysqli etc..
as "drivers".

I think we could discuss going that road as well and we could save
ourselves maintaining some thousands of lines of C code.

May I question the sanity of the words written in this email? :D (it's a
joke).

The whole point of mysqlnd drivers and other improvements was to cut down
on data copying, improving performance and doing a lot of other stuff.
Moving PDO to a PHP implementation will kill it all: preformance will
suffer,

I am totally certain that performance will be that bad. Indeed slower
but in relation to the DB IOs, they could be within an acceptable
margin.

memory usage will skyrocket,

here as well, even less with 7 or already with 5.5+, if done wisely
(did not check PDO lately but it could be improved if not already)

dealing with charsets - I don't even
wana pretend I understand how to deal with that part in a proper fasion.
Doesn't it require access to internal PHP api's to do a lot of what PDO and
other native drivers do?

It is called userland hooks, no big magic required.

See https://pecl.php.net/package/mysqlnd_uh for something similar. Not
really prod ready or whatever but a good example to see how something
similar could be done.

Well, the Zephyr could pitch in here, MAYBE, depending on how good it
actually is and what it can do, but still, it feels more like a cruch to me.

Good point, not sure how far it exposes PHP internals APIs or if it
does it the same way than it does for system libraries :)

Cheers,

Pierre

@pierrejoye | http://www.libgd.org

On Fri, Apr 24, 2015 at 8:16 AM, Arvids Godjuks arvids.godjuks@gmail.com
wrote:

2015-04-24 4:42 GMT+03:00 Benjamin Eberlei kontakt@beberlei.de:

On Thu, Apr 23, 2015 at 3:45 PM, Arvids Godjuks <arvids.godjuks@gmail.com

wrote:

PDO is everywhere. Doctrine? Based on PDO.

You can use mysqli, oci8 or sqlsrv for example without problems in
Doctrine.

Exposing some of the internal api of PDO as php functions (SQL Parser) I
would bet it is possible to reimplement PDO in PHP code using mysqli etc..
as "drivers".

I think we could discuss going that road as well and we could save
ourselves maintaining some thousands of lines of C code.

May I question the sanity of the words written in this email? :D (it's a
joke).

You may question my sanity, but I am totally serious.

The whole point of mysqlnd drivers and other improvements was to cut down
on data copying, improving performance and doing a lot of other stuff.
Moving PDO to a PHP implementation will kill it all: preformance will
suffer, memory usage will skyrocket, dealing with charsets - I don't even
wana pretend I understand how to deal with that part in a proper fasion.
Doesn't it require access to internal PHP api's to do a lot of what PDO and
other native drivers do?
Well, the Zephyr could pitch in here, MAYBE, depending on how good it
actually is and what it can do, but still, it feels more like a cruch to me.

None of these will happen, because PDO doesnt add much value on top of what
the libraries already provide. For example MySQLi, pgsql, oci8 allready
handle charsets, we only need to delegate correctly.

See this very hacky prototype for PDO::prepare/query/bindValue/execute
using a to be exposed API for emulated prepares in PHP code (extracted from
existing PDO code).

https://gist.github.com/beberlei/3dfa960901533e859c02

This is a very thin layer of PHP and given PHP7 is already twice as fast as
PHP5 i don't think anyone would suffer.

2015-04-24 4:42 GMT+03:00 Benjamin Eberlei kontakt@beberlei.de:

On Thu, Apr 23, 2015 at 3:45 PM, Arvids Godjuks arvids.godjuks@gmail.com
wrote:

PDO is everywhere. Doctrine? Based on PDO.

You can use mysqli, oci8 or sqlsrv for example without problems in
Doctrine.

Exposing some of the internal api of PDO as php functions (SQL Parser) I
would bet it is possible to reimplement PDO in PHP code using mysqli etc..
as "drivers".

I think we could discuss going that road as well and we could save
ourselves maintaining some thousands of lines of C code.

May I question the sanity of the words written in this email? :D (it's a
joke).

The whole point of mysqlnd drivers and other improvements was to cut down
on data copying, improving performance and doing a lot of other stuff.
Moving PDO to a PHP implementation will kill it all: preformance will
suffer, memory usage will skyrocket, dealing with charsets - I don't even
wana pretend I understand how to deal with that part in a proper fasion.
Doesn't it require access to internal PHP api's to do a lot of what PDO and
other native drivers do?
Well, the Zephyr could pitch in here, MAYBE, depending on how good it
actually is and what it can do, but still, it feels more like a cruch to me.

Via ADOdb I can use either the PDO or the generic driver. It's actually
how I've been testing pdo_firebird simply by switching the underlying
interface. Much of what PDO is doing is actually no different to the
generic driver as at the end of the day you want an array of data from
one location to another. My own concern has been that all this debate on
'type hints' actually messes up the simple array process where we just
get an array of strings which PHP then uses appropriately. But the
bottom line is perhaps that PDO's 'flattening' of data types can slow
down the process if it introduces conversions which are not really
necessary? In the case of ADOdb, the PDO driver is slower than the
generic driver, which some will say is down to the overheads of ADOdb,
but those overheads in many cases are only the same as any other SQL
abstraction layer. The overall process is what matters, and if you don't
need SQL abstraction, is there any advantage to PDO over the generic
driver if you are only ever using one database? The theory was that
having the same data layer would simplify software design, but it just
introduces another layer of complication.

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

May I question the sanity of the words written in this email? :D (it's a
joke).

The whole point of mysqlnd drivers and other improvements was to cut down
on data copying, improving performance and doing a lot of other stuff.
Moving PDO to a PHP implementation will kill it all: preformance will
suffer, memory usage will skyrocket, dealing with charsets - I don't even
wana pretend I understand how to deal with that part in a proper fasion.
Doesn't it require access to internal PHP api's to do a lot of what PDO and
other native drivers do?
Well, the Zephyr could pitch in here, MAYBE, depending on how good it
actually is and what it can do, but still, it feels more like a cruch to me.

In many many different topics I stressed that we should do things in
userland and use extensions only when needed for performance.

Doing things in userland gives
* better debugability
* better understanding for users
* lower entry barrier
* faster development time
* better ability to evolve (different library versions can coexist
on a system, for old and new code)

With the changes in PHP 7 this is viable for even more areas. What PDO
does is very thin. And mind: If a user truly cares about the last bit of
performance they won't use an abstraction, they use DBMS-specific SQL
and cut out abstractions. But for many cases that level of performance
matters, as usage of ORMs etc. show. Also mind that processing in the
database server and network traffic probably cost way more time than a
thin wrapper even in userspace (in real life, not in "SELECT 1")

johannes