Den søn. 24. mar. 2019 kl. 10.05 skrev Lester Caine <les...@lsces.co.uk>: > > On 24/03/2019 01:42, Kalle Sommer Nielsen wrote: > > Besides this, it has further magic behavior if the multiple > > connections are created with the same credentials as one in the same > > process, I'm not sure if this is fixed with Nikita's patch. > > But that IS the point here ... In fact many people using Firebird with > PHP use it in 'embedded mode', where the client is actually the server > process and explicitly blocks a second physical connection! The default > $link is the initial default transaction and ibase_trans creates > additional links encapsulating additional transactions on the database > if work flow requires. The difficulty and one that PDO can never support > is that a transaction CAN encapsulate two or more different physical > connections and it is this which dictates that operations need an > explicate '$link_or_trans_identifier'. Personally I use $conn and > $transnnn explicitly to keep track of things ... but if you only open a > single physical connection and don't add transactions then the > 'default_link' is the only packet of workflow. > > ibase_connect specifically says > "In case a second call is made to ibase_connect() with the same > arguments, no new link will be established, but instead, the link > identifier of the already opened link will be returned. The link to the > server will be closed as soon as the execution of the script ends, > unless it's closed earlier by explicitly calling ibase_close(). " It was > this action that as broken around 7.0.3 ... and it's probably totally > incompatible with 'thread safe'? But the firebird client can handle > multiple calling processes - and persist connections - so the 'bug' is > probably in how PHP and Firebird interact in a new world? We are still > using a 20+ year old model. > > For a simple single transaction packet of work one opens a connection > does the work and if the activity crashes it is rolled back otherwise it > autocommits when finished. Yes this is magic behaviour but it's the same > magic behaviour that it has always done even on C and Delphi platforms > and for the vast majority of PHP processes it's all that is needed? It's > just not politically correct today?
Your objection to the deprecation and removal of ext/interbase has been noted, and will be recorded at vote time. I would ask that discussion about how ext/interbase works or should work, or how it worked twenty years ago, or how it works in Delphi is conducted elsewhere, as this RFC is around the removal of it. Thank you -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
