Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:104883 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 76676 invoked from network); 23 Mar 2019 12:35:50 -0000 Received: from unknown (HELO mail4.serversure.net) (185.153.204.204) by pb1.pair.com with SMTP; 23 Mar 2019 12:35:50 -0000 Received: (qmail 25520 invoked by uid 89); 23 Mar 2019 09:28:25 -0000 Received: by simscan 1.3.1 ppid: 25513, pid: 25517, t: 0.0517s scanners: attach: 1.3.1 clamav: 0.96/m:52/d:10677 Received: from unknown (HELO ?10.0.0.7?) (lester@lsces.co.uk@81.138.11.136) by mail4.serversure.net with ESMTPA; 23 Mar 2019 09:28:25 -0000 To: PHP internals Message-ID: <2f7acce4-69dd-d98b-6f86-1110e3589c4b@lsces.co.uk> Date: Sat, 23 Mar 2019 09:28:25 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Subject: Firebird - Who are WE ... From: lester@lsces.co.uk (Lester Caine) Over twenty years ago Borland took over Ashton Tate to bring dBase into the Borland tool set. What they did not appreciate at the time was that Ashton Tate had taken over Interbase to provide a proper multi-user database engine to augment dbase. The bean counters at Borland decided there was no margin in the Interbase part of Ashton Tate and announced it would be end of lifed! They did not appreciate at the time just how many people had moved from dbase over to Interbase and how many businesses were then reliant on it. In a knee jerk reaction to calm things down they offered to open source the code ... and long story short Firebird came into existence. The bean counters THEN began to realise what a cash cow Interbase could become or rather could have become so the end of life was rescinded, but the the cat was already out of the bag. Roll forward 10 or so years and PHP drops the Interbase driver from the windows builds. Well actually there were no official windows builds so we had to rally around and provide them, but the drive to sort out building PHP on the newer windows compile stacks saw the interbase driver pushed to the side "because Firebird did not support compatible builds!". So we just carried on providing them outside the PHP project along with other key elements like imagick! The key reason for not allowing Firebird into windows builds was that it's client library was no compatible with the build set and that Firebird needed to be compiled with the same version of windows compiler. This did not make sense then just as it does not now. A database engine is a stand alone section of code and may well be running on a completely different machine so why should the version of windows used make any difference ... if the server is on Linux? The important bit is that the LOCAL client program can be linked to the local user - in this case PHP. With the windows setup the interbase extension paired with the firebird client and all that needed to be done to access a newer Firebird server was to load the newer client onto the machine. The link between the interbase extension and the firebird client has not changed in many years. So today to switch from PHP connecting to a production FB2.1 or FB2.5 to an FB3 machine we simply install the correct client and do nothing with the interbase extension. Today there are problems IN the interbase extension caused by the way PHP now handles a 'resource' such as a database connection. Firebird (and Interbase) has the ability to create transactions between two or more active connections and commit or roll back all as required. PDO does not allow multiple connections at all so there is no way to action it via PDO so the interbase extension is the only way to access it. I think that part of the problem of the way the resource handling has been updated in the extension is down to not understanding this element and yes someone who understands firebird needs to maintain this but it's the way that PHP has changed the API which also needs to be understood. *I* have tried to keep up to speed with the PHP side of things, but having submitted fixes in the past, trying to decipher what Nikita is trying to do in this latest patch is difficult looking at the code in isolation since there are lots of 'system' calls that I don't follow. Personally I don't need more than a single link to a single database so everything still works for me anyway, but with persistent connections I presume the resource links should be managed at a higher level anyway? On my own development platform I think using hg-git to access the php-src repository is now impossible. Since yesterday afternoon I've downloaded 896 commits of the 24601 I'm behind, so while THG works perfectly for all the key components such as ADOdb, smarty and ckeditor, if I'm going to work with php code I'm going to have to bypass that! Which is yet another learning curve when the one I am on works well to provide the input that I do provide. ADOdb has been kept up to date with the changes in questions and results passed over the link but to date nothing major has changed in 20+ years in the process of sending a query to the database and getting a result set back ... although handing the new authentication methods added in FB3 may benefit from a major rebuild of the extension, which WOULD require that the fbird_ aliases are moved to their own build of the extension, being completely incompatible with current builds of Interbase. -- Lester Caine - G8HFL ----------------------------- Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk