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 features that are on the roadmap of other database projects, this approach probably means that these extra methods will probably become generic over time ;)
I would opt for the least painful solution possible, and that would be to allow the 'native' functions to be used through PDO in some way if no solution has been implemented specifically. Maybe we could discuss this some more sometime.
My own thought is that there could be some 'cross-fertilisation'? I know the idea of linking PDO to the native drivers has been shelved, but in the case of php_interbase wouldn't some kind of link be a simple short term solution? You know the code Ard - how difficult would a 'mind meld' be - perhaps just dropping everything into pdo_firebird as 'extras'?
Right now, the PDO class is geared up for providing access to your data. Pretty much everything else that has been quoted as bad or missing features are either fringe features or fringe use cases, compared to the typical uses of PHP: getting data out of the database and showing it on a web page.
Of course. But in the case of Firebird, these fringe features - as you call them - may well have been the reason someone uses Firebird in the first place. The whole reason I ever got involved with developing PHP/Firebird is because the whole multiple transaction thing had never been implemented in PHP, and I needed it for a project.
Something that needs pointing out is that the traditional 'market' for Firebird users is CBuilder/Delphi/JBuilder, since Interbase used to be supplied free to all Borland 'pro' developers. *I* don't like the way Borland has moved all of its development base to support .NET and had apparently end of lifed C++ support :( , so was looking for an alternative. PHP4 looked attractive, but had a major problem - the poor capability of the Interbase driver. Ard plugged that hole at just the right time, with his additions to the PHP5 builds, and so I have never used PHP4, starting customer site on pre-release PHP5 simply because of the Firebird interface.
*NOW* I am trying to convince other developers that PHP is a suitable alternative as a move from CBuilder as .NET or C#. Borland have now backpedaled a bit on their 'end of life' of CBuilder in much the same way as they did with Interbase back in 1999, but I am now committed to switch all my sites to a an Apache/PHP/Firebird base as customers will accept that. Another 4 sites are on the books to move next month, and 50 odd legacy sites are reviewing the situation. Those sites that have moved like the arrangement so much that they are talking to us about moving other facilities into our core Client Management System, from Oracle and MSSQL databases, and so we are increasing the cross platform requirements.
The MAJOR hurdle when customers tell their IT departments what they want to do ( we traditionally dealt direct with the front line staff as we supply caller area displays, CCTV, panic alarm, PA .. Oh - and the caller ticketing system ;) ) is first Firebird itself, but that has been an easy 'sale'. The image that Apache/PHP is always bundled with Linux and MySQL (LAMP has created a life of it's own!) is more difficult to get round. Many IT departments still think Linux / MySQL / Micky Mouse, but Apache2 + Windows + PHP5 + Firebird can be quickly demoed, and it's nice to be able to access data from their in house systems in parallel with the Firebird data with very little work.
And PDO *will* have to be changed to allow for the more exotic features of Firebird.
Nope, the firebird driver can implement them as driver specific features. They're so exotic that no other database implements them; it doesn't make sense to redesign just for firebird.
OK, as long as that is possible, I'm fine with it.
Again - the bulk of Firebird's 'exotic' features are on the 'TODO' list of most of the other engines - Triggers - Stored Procedures - etc are already appearing. Many Oracle 'exotic' features came from the same base as they appeared in Interbase over it's 20 year history.
So the 'problem' is to convince a large population of Firebird users that PHP is something they should consider, and plug the holes that hinder that move, rather than pushing the idea that there is no demand for Firebird from PHP users. An increasing number of current Oracle users are looking at hikes in their licensing bill and asking what they can do to cut it. Firebird can swallow most Oracle data without a hiccup ( there is even an Oracle-mode project 'Fyracle' ), and PHP provides a nice additional platform independent interface to further support it.
So current 'demand' for Firebird in PHP is low, but some of use are trying to grow the penetration of PHP into Firebird heavy areas ;)
-- Lester Caine ----------------------------- L.S.Caine Electronic Services
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
