Lester,
ext/ibase is still around and will still be maintained. nothing lost.
ext/pdo might eventually make ext/ibase obsolete. the interim goal is
not that lofty _yet_.
So chill, talk to your delphi/firebird friends of the greatness that is
ext/ibase on PHP5 and let this bickering over ext/pdo
Ard Biesheuvel wrote:
[Excuse my ignorance: haven't worked on PHP for a while] Does this mean
the DB-specific derivations of the PDO classes can/will have methods no
other drivers support? Something like
PDO_FIREBIRD::startMultiple($db1,$db2)?
Given the number of currently Firebird specific feat
Wez Furlong wrote:
5.1 beta is scheduled for March 1st, and we'll follow that with the
usual RC process. I think you have a little bit of time; the changes
OK.
For instance (these issues have been pointed out by me before):
- Firebird has transactions over multiple connections [no JOINs between
da
aha !!!
http://www4.dogus.edu.tr/bim/bil_kay/prog_dil/c++/index.htm
chapters 16 - 21. now off to the dungeon
"L0t3k" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>i think i may have found enough info to do a "Hello World" driver. there
>actually used to be a full book online de
i think i may have found enough info to do a "Hello World" driver. there
actually used to be a full book online describing DB programming under VC++
(with some decent code examples), but i've long since lost the link. i'll
google till i find it.
"Wez Furlong" <[EMAIL PROTECTED]> wrote in messag
ADO will probably suck, as it layers on top of OLE-DB, IIRC.
Probably better to stick with ODBC in that case :)
--Wez.
On Tue, 15 Feb 2005 16:55:24 -0500, l0t3k <[EMAIL PROTECTED]> wrote:
> thanks Wez,
> i'll take a look. if it gets too hairy, i'll investigate ADO ...
>
> "Wez Furlong" <[EMAIL
thanks Wez,
i'll take a look. if it gets too hairy, i'll investigate ADO ...
"Wez Furlong" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>I heard from Frank that it's really painful.
>
> You should be able to find the SDK on msdn.microsoft.com somewhere.
>
> --Wez.
>
--
PHP Intern
I heard from Frank that it's really painful.
You should be able to find the SDK on msdn.microsoft.com somewhere.
--Wez.
On Tue, 15 Feb 2005 16:24:39 -0500, l0t3k <[EMAIL PROTECTED]> wrote:
> Wez,
> do you know if some resources for ole-db ? when i was silly enough to
> try and write my own a
Wez,
do you know if some resources for ole-db ? when i was silly enough to
try and write my own abstraction layer, that was the one that got away. if i
had some code/samples/documentation, i'd try my hand at supporting it
"Wez Furlong" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PR
On Tue, 15 Feb 2005 17:24:05 +0100, Ard Biesheuvel <[EMAIL PROTECTED]> wrote:
> Hi everyone, long time no post!
Welcome back Ard :)
> What would be a reasonable deadline for this (in relation to 5.1) ?
5.1 beta is scheduled for March 1st, and we'll follow that with the
usual RC process. I thin
George Schlossnagle wrote:
PHP has long suffered from poor implementations of some of the DB
extensions and good implementations of others. PDO is a good
opportunity to unify the extensions and have a common code base so
that bug fixes
Excuse my ignorance, maybe I missed the answer to Lester's q
Hi everyone, long time no post!
Wow, a lot has happened to PDO while I was looking the other way for a
minute. I hope I will soon find the time to bring PDO_FIREBIRD up to
date with all the recent changes.
What would be a reasonable deadline for this (in relation to 5.1) ?
Lester Caine wrote:
>
On Feb 15, 2005, at 2:57 AM, Lester Caine wrote:
Christian Schneider wrote:
Andi Gutmans wrote:
PHP has long suffered from poor implementations of some of the DB
extensions and good implementations of others. PDO is a good
opportunity to unify the extensions and have a common code base so
that b
Lester Caine wrote:
In addition, while the Transaction interface can be compressed into the
straight jacket that PDO defines, it would be nice to commitRetaining,
but that is something that can be addressed once the need to run the
native driver as well as been removed.
We did discuss the topic
Christian Schneider wrote:
Andi Gutmans wrote:
PHP has long suffered from poor implementations of some of the DB
extensions and good implementations of others. PDO is a good
opportunity to unify the extensions and have a common code base so
that bug fixes
Excuse my ignorance, maybe I missed the
That's also something of a hack (PDO core doesn't and shouldn't know
about mysql specific features).
It's better to have a generic mechanism for this, such as the
"interfaces" idea I mentioned a couple of years back.
I don't think there will be time to wedge that into 5.1 though :-/
--Wez.
On
It would be usefull if there was a shared struct for this in pdo core: eg.
(in /ext/pdo/php_pdo_drivers_extras.h)
(mysql_do_something_ptr *) mysql_do_something(pdo_stmt_t *,char *
an_argument)
pdo_driver_extras_mysql {
mysql_do_something_ptr *mysql_do_something,
}
So th
Yes I very much agree with Wez.
PHP has long suffered from poor implementations of some of the DB
extensions and good implementations of others. PDO is a good opportunity to
unify the extensions and have a common code base so that bug fixes
propagate to all extensions (at least in most cases). O
Depends on the functionality.
Drivers are free(*) to implement driver specific methods on the PDO
and PDOStatement objects, provided they are "namespaced"
eg:
$db->mysqlDoSomething()
would be a mysql driver specific feature.
More generic attributes can be accessed or set via the get/setAttribu
Andi Gutmans wrote:
PHP has long suffered from poor implementations of some of the DB
extensions and good implementations of others. PDO is a good opportunity
to unify the extensions and have a common code base so that bug fixes
Excuse my ignorance, maybe I missed the answer to Lester's question
On Feb 12, 2005, at 5:01 AM, Lester Caine wrote:
Derick Rethans wrote:
1. ADOdb has *nothing* to do with the PHP project
It would not exist without it.
No reason why it could not be part.
Plenty of things couldn't exist without PHP. That doesn't mean that
PHP needs to hold still for their sake, o
Derick Rethans wrote:
1. ADOdb has *nothing* to do with the PHP project
It would not exist without it.
No reason why it could not be part.
2. Some people don't need bloated libraries as ADOdb and still want to
have one single unified interface to databases - THAT is what PDO is
for: raw acces
On Sat, 12 Feb 2005 09:43:52 +, Lester Caine <[EMAIL PROTECTED]> wrote:
> I don't see that I am making a fool of myself?
Just about everyone I've met would feel at least embarrased if not
downright foolish if they had done what you have just done,
particularly given the number of people subscr
Wez Furlong wrote:
Until PDO has all the same drivers - ADOdb would become a mess, so there
is little incentive to start changing, and to be honest, you would have
to PROVE that PDO is as fast as the raw database drivers to warrant a
change from them.
Right. Try it. It's faster than adodb, I assu
Lester Caine wrote:
Wez Furlong wrote:
You're missing the point.
No *YOU* are missing the point.
Lester, have you bothered to read the code at all?
PDO is to databases what SAPI is to web servers. It is a layer in the
guts of PHP that will one day make it much easier to maintain and add
new dat
On Sat, 12 Feb 2005, Lester Caine wrote:
> Wez Furlong wrote:
>
> ADOdb is a well established abstraction layer.
And there are others too: pear:db, mdb, metabase...
> > If you want a database abstraction layer, stick with ADOdb and let
> > John adapt that to run on top of PDO.
>
> GE!!
>
I'm sorry, you're right and we're all wrong. All of us. We, the
stupid core developers of PHP, have been, for more than 2 years
off-and-on, discussing the wrong solution to the problem. How could
we be so blind? Aren't we dumb?
We are mistaken that the C code is inconsistent and needs fixing.
Wez Furlong wrote:
You're missing the point.
No *YOU* are missing the point.
ADOdb is a well established abstraction layer. There have been many
other attempts to provide the same facilities ( e.g PearDB ) and they
are all playing catchup. ADOdb tries to assist by mapping functions so
that peopl
You're missing the point.
PDO isn't a replacement for ADOdb, it's a future replacement for
ext/mysql, ext/pgsql, ext/oci8, ext/odbc, etc. etc. etc.
If you want a database abstraction layer, stick with ADOdb and let
John adapt that to run on top of PDO.
WHY can't you be bothered to read the resou
Wez Furlong wrote:
It's the weekend, time for relaxation and recreational hacking.
The perfect opportunity to give PDO a whirl :-)
Wez
I have had a look at PDO, but for many of us it is just a step BACK to
the bad old days.
ADOdb is well established and works. If you use the accelerator module
th
30 matches
Mail list logo
