Re: [PHP-DEV] [RFC] Unbundle ext/interbase
On Mon, 25 Mar 2019 at 23:04, Stanislav Malyshev wrote: > > In my opinion, deprecation warnings should be used for functionality > that the used needs to remove from the code. That's not what we're doing > here - That's a good point. Another thing that probably needs consideration is that if/when someone from the Firebird community steps up to maintain the extension, at some point it would probably be appropriate to fork the extension to be named Firebird, rather than ibase, as it appears that Interbase and Firebird have forked and are no longer fully compatible with each other: https://ib-aid.com/en/articles/differences-between-firebird-and-interbase/ > InterBase was created in 1985: it was the first commercial multi-versioning > database. In the end > of 1999, Borland decided to close InterBase development and published its > source codes under > InterBase Public License. This code was copied (it is permitted by the > license), and Firebird > was born – from the version 1.0 Firebird is a production-ready database, > based on > previous decades of InterBase development. > > > > Since then, the difference between Firebird and InterBase became bigger. It would be pretty reasonable for a maintainer from the Firebird community to maintain the extension for Firebird compatibility, rather than maintaining it to be Interbase compatible. But having it still be named after Interbase would be quite confusing. The exact details of that can be discussed after the vote, and when someone applies to maintain it. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Unbundle ext/interbase
Hi! > I see the following options to go about this extension: > > 1) Add a deprecation warning as the functionality will effective cease > to exist in php-src. We don't know if this extension will be taken As an end user (in this case, PHP developer that needs to use Firebase functionality), I couldn't care less where the source code that compiles to the extension lives - php-src or pecl. So warning me about that is not very useful for me. If it gets moved to pecl, I'll discover it from UPGRADING note, amend my install list to fetch the pecl package and that should be the end of the matter for me. In my opinion, deprecation warnings should be used for functionality that the used needs to remove from the code. That's not what we're doing here - and that's not realistic for us to ask people to do, since it's not likely they'd just drop their DB backend. They'd use PECL package instead, or older version. The proper place to warn about this is the release notes (UPGRADING), not runtime deprecation warnings. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Unbundle ext/interbase
On 24/03/2019 13:47, Dan Ackroyd wrote: It's worth noting that even after the extension is moved from core to it's own repository, most people using it on Debian or Centos/Redhat/Fedora won't notice any difference. On one hand this is correct but the reason I got stung with a move to PHP7.2 before I was ready was because SUSE pulled the 7.0 repo despite 7.0 being the LTS version on that base distribution. I needed to rebuild a machine, but the key component was not available ... and in hindsight I should probably have pulled a copy of 7.0 from php.net rather than taking the 7.2 replacement. On one hand we get good support from the various distributions, but being able to dovetail that in with the main project can be essential at times! Being ALLOWED to select when we have completed upgrading our end to be compatible is rather important these days, given the much faster upgrade cycles, but not always easy where distros 'keep up to date' automatically :( And even more difficult when they stick with an older version when you need the updated one :( -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Unbundle ext/interbase
On Sun, 24 Mar 2019 at 12:32, Rowan Collins wrote: > Presumably the PECL extension... the new home of the extension gets more > publicity. > It's worth noting that even after the extension is moved from core to it's own repository, most people using it on Debian or Centos/Redhat/Fedora won't notice any difference. The maintainers of those distributions already package the ibase/firebird extension separately to PHP core, and where the code for that extension comes from won't make any difference to end-users. The only difference the RFC will make to those people is that it will remove the false promise that the code is currently maintained by PHP core people. cheers Dan
Re: [PHP-DEV] [RFC] Unbundle ext/interbase
Hi Peter Den søn. 24. mar. 2019 kl. 14.39 skrev Peter Kokot : > I'm all in for helping out here with both users using this and > maintainers that need to worry about if this extension is even working > ok. However, just one quick thought. The deprecation usually means > that some functionality will cease to exist. And users usually expect > and consider removing deprecated usage from their code and move to > something else. Not that they will have an option to install it over > PECL in PHP 8.0... Is this ok approach for this case? Because with > this approach PHP is also saying quietly that PECL is a museum for > extensions and not a place for developing them further. I might be > completely wrong here though... I opted for the deprecation warning as the functionality will effectively cease to exist in php-src, we have done similar things to other extensions (recently ext/wddx) or even ext/mysql (which did have the ext/mysqli and ext/pdo_mysql) as alternatives, similar ext/interbase have the ext/pdo_firebird alternative. I see the following options to go about this extension: 1) Add a deprecation warning as the functionality will effective cease to exist in php-src. We don't know if this extension will be taken over if it ends up in PECL, so this is the safe bet, which is why I opted for this initially in the RFC 2) Silently remove it already in 7.4, this is also a very viable option, but it does not give the users to think about alternatives, We did this for some extension in 5.6 -> 7.0, like ext/mssql. If we go with this option, it means that there is no warnings and that whoever picks up the extension (if any) can give them a warning free environment. I can amend the RFC to have these voting choices in mind if it is preferable, similar to ext/wddx. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Unbundle ext/interbase
Hello, On Fri, 22 Mar 2019 at 14:26, Kalle Sommer Nielsen wrote: > > G'day internals > > I'd like to start the discussion for the future of the ext/interbase > extension: > https://wiki.php.net/rfc/deprecate-and-remove-ext-interbase > > The rationale for pushing this extension out of the core is mentioned > in the RFC. > > Unless there is any serious issues raised here, then I will put this > into voting on Monday 8th of April, noon EET (which is a good two and > a half weeks away). The intended voting period is set for 2 weeks, > meaning if voting proceeds, the pools will be closed around Monday > 22th of April, noon EET. > > -- > regards, > > Kalle Sommer Nielsen > ka...@php.net > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > I'm all in for helping out here with both users using this and maintainers that need to worry about if this extension is even working ok. However, just one quick thought. The deprecation usually means that some functionality will cease to exist. And users usually expect and consider removing deprecated usage from their code and move to something else. Not that they will have an option to install it over PECL in PHP 8.0... Is this ok approach for this case? Because with this approach PHP is also saying quietly that PECL is a museum for extensions and not a place for developing them further. I might be completely wrong here though... -- Peter Kokot -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Unbundle ext/interbase
On 24 March 2019 11:33:45 GMT+00:00, Lester Caine wrote: > problem then is that PHP7.4 >essentially becomes a nogo zone because there is no way to remove the >deprecation warnings Presumably the PECL extension, with no deprecation warnings, could be set up straight away, and builds offered for PHP 7.4. That way, the deprecation notices are immediately actionable, and the new home of the extension gets more publicity. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Unbundle ext/interbase
On 24/03/2019 10:58, Kalle Sommer Nielsen wrote: Your objection to the deprecation and removal of ext/interbase has been noted, and will be recorded at vote time. I have no doubt the rfc will go through, my problem then is that PHP7.4 essentially becomes a nogo zone because there is no way to remove the deprecation warnings and hiding them also hides the deprecation messages that can and do need addressing :( Despite the politically correct action of hiding all errors/warnings on production machines, I've always displayed them and I'm not about to change that habit as an error message is much better than a white screen any day. Although I still get white screens as well :( -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Unbundle ext/interbase
Den søn. 24. mar. 2019 kl. 10.05 skrev Lester Caine : > > 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
Re: [PHP-DEV] [RFC] Unbundle ext/interbase
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? -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Unbundle ext/interbase
Den søn. 24. mar. 2019 kl. 03.11 skrev Lester Caine :
>
> (Neely forgot to fix reply address!)
>
> On 24/03/2019 00:22, Kalle Sommer Nielsen wrote:
> > mysql_connect('localhost', 'user', 'password');
> > mysql_select_db('test'); // The last created connection is implicitly added
> > here
>
> This situation never exists in Firebird or Interbase. The ONLY way to
> connect is to a database, you can not connect to the server without
> using a database in the connection string. Each database is it's own
> file or set of files if spread across multiple disks. There is no way of
> asking a server what databases are available, you have to know
> beforehand. Although some newcomers call it a bug it's an original
> design feature.
Really Lester, really. It was a pseudo example, do I really need to be
EXPLICIT and spell everything out very specifically for you?
ibase_connect('localhost:/path/to/some/db.gdb', 'user', 'password');
ibase_query('UPDATE a_table SET a_column = 1'); // The last created
connection is implicitly added here
What happens here is that PHP retain the last connection created by
ibase_connect() and uses it as a "default" link, meaning you do not
pass a connection resource to ibase_query() afterwards.
Compare the example to:
$link = ibase_connect('localhost:/path/to/some/db.gdb', 'user', 'password');
ibase_query($link, 'UPDATE a_table SET a_column = 1'); // Explicit, as
the first parameter is a connection resource
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.
> I'll add BOOLEAN to https://phpsurgery.org/tests/ibtest.php tomorrow,
> but there are bugs in your link that don't show in the link I have been
> using :( But some of them are not bugs ...
Then use the link from the statistics page on bugs.php.net? There is
probably a fair few for PDO_Firebird too you can find on that page
--
regards,
Kalle Sommer Nielsen
ka...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Unbundle ext/interbase
(Neely forgot to fix reply address!)
On 24/03/2019 00:22, Kalle Sommer Nielsen wrote:
mysql_connect('localhost', 'user', 'password');
mysql_select_db('test'); // The last created connection is implicitly added here
This situation never exists in Firebird or Interbase. The ONLY way to
connect is to a database, you can not connect to the server without
using a database in the connection string. Each database is it's own
file or set of files if spread across multiple disks. There is no way of
asking a server what databases are available, you have to know
beforehand. Although some newcomers call it a bug it's an original
design feature.
I'll add BOOLEAN to https://phpsurgery.org/tests/ibtest.php tomorrow,
but there are bugs in your link that don't show in the link I have been
using :( But some of them are not bugs ...
--
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Unbundle ext/interbase
Hi Lester
Den lør. 23. mar. 2019 kl. 23.41 skrev Lester Caine :
> Thread safety is one area where the way the extension was structured
> originally may now be wrong, but the main problem with multiple
> connections is confined completely to multiple connections to a single
> database. In particular the 'default link' is actually the default
> transaction handle and additional links are simply multiple transactions
> on the one connection which I think is where some of the confusion has
> come from :( A more established Firebird user would simply start a new
> transaction, while a newbie may try to start a new connection. And in
> the past the extension has hidden that and quietly picked up the
> existing one ...
The default link should not be related to thread safety, it should be
related to the design of how database extensions used to be working.
The design was as follows (using the old ext/mysql as an example
here).
mysql_connect('localhost', 'user', 'password');
mysql_select_db('test'); // The last created connection is implicitly added here
This is the "default" link. This is some magical behavior which made
the API very easy to use, however it also created some hard to debug
situations with multiple connections. ext/interbase seems to still go
by this design which is most likely the reason to why some of the
weirdness of the extension behavior after the blind updates to
somewhat work on PHP7.
Regarding the connection and fork(), is this a problem in other
database extensions, if not, then it may be worth it for whoever ends
up picking up the extension to look at how others do this. The design
of this extension is fairly old and prone to unforeseen errors.
> "A small subset of field types are supported, anything else crashes"
> This is news to me ... is there any bug report to back it up? All the
> current data types provided by Firebird are working in the extension,
> but you may well be right that we may be better off cloning the existing
> code and building a Firebird only port going forward. The concern is the
> same one we had with windows in the past, where adding extra extensions
> does not always work reliably ... one has to provide a wrapped package
> with all the edge cases addressed. But all my use in production is using
> ADOdb to wrap the database SQL problems ...
I count 13 open bugs[1] in regards to ext/interbase thats been
reported, there are probably a ton more. Bug#74946 talks about a crash
with a type, leading me to believe that if one type can crash, then
more are very likely too.
[1]
https://bugs.php.net/search.php?cmd=display_type=All=Open_name%5B%5D=InterBase+related=Any=30
regards,
Kalle Sommer Nielsen
ka...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Unbundle ext/interbase
On 23 March 2019 21:09:35 GMT+00:00, Kalle Sommer Nielsen wrote: > the extension can be taken over by anyone who >wants to from the relevant community, it just will not be distributed >by default with PHP. In fact if the extension is released on PECL, it >gives the relevant community more freedom to deal with the extension >as they deem fit and does not have the strict requirements as >extensions in the Core has. Sources and binaries are still available >with the PECL interface. It's probably worth noting the example of Microsoft SQL Server here: the previous PHP extensions were dropped from the core in 7.0, and Microsoft now manages an open-source, cross-platform extension, and is able to release it as often as they want, and bring in features and bug fixes to encourage its use: https://github.com/Microsoft/msphpsql For an extension connecting to any actively developed third-party system, this is probably actually the best model, with PHP Internals experts providing advice where necessary, and third-party experts tracking innovations in the particular system. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Unbundle ext/interbase
On 23/03/2019 21:09, Kalle Sommer Nielsen wrote: I updated the RFC with a section earlier to list some of the issues the extension currently has. Thread safety is one area where the way the extension was structured originally may now be wrong, but the main problem with multiple connections is confined completely to multiple connections to a single database. In particular the 'default link' is actually the default transaction handle and additional links are simply multiple transactions on the one connection which I think is where some of the confusion has come from :( A more established Firebird user would simply start a new transaction, while a newbie may try to start a new connection. And in the past the extension has hidden that and quietly picked up the existing one ... "A small subset of field types are supported, anything else crashes" This is news to me ... is there any bug report to back it up? All the current data types provided by Firebird are working in the extension, but you may well be right that we may be better off cloning the existing code and building a Firebird only port going forward. The concern is the same one we had with windows in the past, where adding extra extensions does not always work reliably ... one has to provide a wrapped package with all the edge cases addressed. But all my use in production is using ADOdb to wrap the database SQL problems ... -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Unbundle ext/interbase
Den lør. 23. mar. 2019 kl. 22.59 skrev Lester Caine : > So is there anything else which is required to bring the extension up to > date? There is nothing above that prevents the extension doing it's job > for the vast majority of users and even the suggestion that it is > unusable due to Bug 72175 does not stand up to scrutiny and can now be > fixed in 7.3 and 7.2 anyway ... I updated the RFC with a section earlier to list some of the issues the extension currently has. Like Joe said in the other thread, it does bad bad things in ZTS among some of the serious issues. Even if these things are fixed, we do not have a guarantee to have someone who is capable of dealing with the issues at hand in the future, nor do I see fixing bug#72175 as a reason to halt this RFC. Like I have expressed to people who has mailed me off list (which is inappropriate) that the extension can be taken over by anyone who wants to from the relevant community, it just will not be distributed by default with PHP. In fact if the extension is released on PECL, it gives the relevant community more freedom to deal with the extension as they deem fit and does not have the strict requirements as extensions in the Core has. Sources and binaries are still available with the PECL interface. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Unbundle ext/interbase
On 22/03/2019 13:26, Kalle Sommer Nielsen wrote: I'd like to start the discussion for the future of the ext/interbase extension: https://wiki.php.net/rfc/deprecate-and-remove-ext-interbase Currently I am seeing 6 open bugs against ext/interbase going back to 2009 ... 48447 - 2009 The oldest bug relates I think to threading and I think the problem here is trying to use the same connection opened in one thread in the child thread. Close the connection then fork and I am presuming it will work, but I don't have pcntl loaded in production and had to add it to the test setup ... but don't know what I would use it for, but it may be appropriate to use with Firebird's events interface. 62300 - 2012 Tomorrows job ... have the files downloaded now, but I don't recognise the problem as we use null all the time to trigger the database generator code. 71650 - 2016 We do have it documented http://www.janus-software.com/fbmanual/man.php?book=php and it may be necessary to separate it out from the interbase extension to cope with Firebird 4 which adds new data types! 72175 - 2016 The patch nikita has proposed works nicely now I've got it running on 7.2.16 ... the WAY duplicate connections to the same database are handled may be part of the problem with Bug 48447 ... 74076 - 2017 The reported bug is not repeatable, but using the wrong resource id will trigger a seg fault. Not sure if it's possible to detect the mistake and error instead. 74104 - 2017 Again not able to duplicate, but it looks like it's a matter of replacing strptime which should be something I can address in isolation. Getting dates in is the biggest problem everywhere. So is there anything else which is required to bring the extension up to date? There is nothing above that prevents the extension doing it's job for the vast majority of users and even the suggestion that it is unusable due to Bug 72175 does not stand up to scrutiny and can now be fixed in 7.3 and 7.2 anyway ... -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Unbundle ext/interbase
On Fri, 22 Mar 2019 at 13:26, Kalle Sommer Nielsen wrote: > G'day internals > To everyone reading this thread please note: Although people are free to discuss RFCs amongst themselves off-list, it is not appropriate behaviour to contact people discussing an RFC on this list through other communication channels. Any communication about the topic that you want to send to someone in this thread should be sent via the PHP internals list. cheers Dan Ack * unless of course you know the person yourself off-list.
Re: [PHP-DEV] [RFC] Unbundle ext/interbase
On 22/03/2019 16:25, Nikita Popov wrote: I've created a patch forhttps://bugs.php.net/bug.php?id=72175 (last comment), which seems to be the biggest open problem in the interbase extension. I'd appreciate it if you or someone else who uses firebird could test this. OK now got a test framework on the development machine where I can check things out. As expected, starting two connections to two different databases just works and simply copying $link to $link1 works as one would expect. But trying to create a second connection to the same database is currently giving me a crash and 'undefined symbol: GC_ADDREF' So I need to tidy up the patch to work with 7.2.16 :( The other part of the jigsaw is working out the significance of the 'default_link' in the code. And I'm taking this back to the firebird developers to check something out. As far as I am aware the firebird CLIENT will reuse an active connection to the database, but if one creates several connections in PHP and a couple end up linking to the same database where does a default one come into the picture. I think the code is basing decisions on the first connection made? Rather than the poll of active connections ... As stated in the bug report, there is no need to reconnect to the same database, but there will be a default transaction for the connection which requires explicit transactions to be handled and this may be why there is thought to be a need to open new connections when one simply manages extra transactions on the same link. Working of a singleton link just works and so in that case the bug is irrelevant rather than a show stopper. -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Unbundle ext/interbase
On 22/03/2019 16:25, Nikita Popov wrote:
I've created a patch forhttps://bugs.php.net/bug.php?id=72175 (last
comment), which seems to be the biggest open problem in the interbase
extension. I'd appreciate it if you or someone else who uses firebird could
test this.
Nikita
Am I jumping the gun a bit? I've got 7.2.16 configured so I can compile
it myself. It's throwing a warning on compile
./ibase.h:761:28: note: expected ‘ISC_UCHAR ** {aka unsigned char **}’
but argument is of type ‘char **’
ISC_LONG ISC_EXPORT_VARARG isc_event_block(ISC_UCHAR**, but the
compiled copy is clearing my ibtest suite.
I've ported your patch to the 7.2.16 copies of the files but this is
throwing a different warning
"implicit declaration of function ‘GC_ADDREF’;" and GC_DELREF
GC_ADDREF certainly exists in the file already but not GC_DELREF so am I
missing something that will stop me making this work on 7.2.16?
It is at least running - http://smallbrook.co.uk:800/phpinfo.php but I
need to add something to test this problem as my framework only uses a
singleton connection ... http://smallbrook.co.uk:800 needs a login, but
the database searches are running fine.
I'm still waiting on mercurial syncing with git but hopefully in the
morning I'll be able to cross check changes in the files over time.
--
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Unbundle ext/interbase
On Fri, Mar 22, 2019 at 3:10 PM Lester Caine wrote: > On 22/03/2019 13:26, Kalle Sommer Nielsen wrote: > > G'day internals > > > > I'd like to start the discussion for the future of the ext/interbase > extension: > > https://wiki.php.net/rfc/deprecate-and-remove-ext-interbase > > > > The rationale for pushing this extension out of the core is mentioned > > in the RFC. > > > > Unless there is any serious issues raised here, then I will put this > > into voting on Monday 8th of April, noon EET (which is a good two and > > a half weeks away). The intended voting period is set for 2 weeks, > > meaning if voting proceeds, the pools will be closed around Monday > > 22th of April, noon EET. > > It is not that we don't want to stand up and maintain it, it has been > impossible in recent years to get a handle on just what needs to be done > TO maintain it. The PDO extension is in a much worse state than the main > interbase one but both of them do their jobs as well as they can given > that in the case of PDO it can't handle the cross database transactions, > something that the main extension does quite happily. > > Personally I've been wasting time recently trying to keep alive sites > that are using MySQL and the main problem with MySQL is the one thing > that Firebird does nicely. Backup just runs as a secondary cron job > independent of PHP while MySQL is reliant on PHP and current backups on > some wordpress powered sites are failing because they run out of time or > memory. I've never had a problem with loosing data with Firebird while > I've had recover MySQL situations a few times in the last year! > > So all we are asking for is HELP with the code changes that result from > changes to the PHP API to keep this available. > Hi Lester, I've created a patch for https://bugs.php.net/bug.php?id=72175 (last comment), which seems to be the biggest open problem in the interbase extension. I'd appreciate it if you or someone else who uses firebird could test this. Nikita
Re: [PHP-DEV] [RFC] Unbundle ext/interbase
On Fri, 22 Mar 2019 at 14:10, Lester Caine wrote: > > it has been impossible in recent years to get a handle > on just what needs to be done TO maintain it. Yes, figuring out what needs to be done takes more time that writing the code. Did you not know this? This is what takes up most of my time as the maintainer of the Imagick extension. I hardly write any code for it, instead I spend a lot of time trying to figure out: * what has changed upstream? Do I need to support that change? * is this bug report valid? which involves spending time trying to recreate it. * how is a feature of it that I've never used myself meant to work? * what needs more documentation? And then writing that documentation. All of that is tediously boring to me, and yet I still do it because I care just enough to avoid the extension from being considered abandoned. We've had this discussion about the interbase extension multiple times. Each time people have said they will step up to maintain it. But apparently each time no-one actually cares enough to commit the time to be up-to-speed and maintain the extension. > So all we are asking for is Who is we in this sentence? Is it end-users who claim that it's a vital part of their business, but haven't actually contributed enough of their time to maintain it? Or is it the billion dollar company that bought Interbase ( https://www.ideracorp.com/brands), and has recently bought Travis CI, and yet doesn't want to hire someone to maintain the extension? In either case, you are asking people who do not use a piece of software to donate their own time maintaining it. btw please do not cross post to multiple groups. If you want to make the firebird developers aware of this proposal you should do separately from your emails to PHP internals. cheers Dan Ack
Re: [PHP-DEV] [RFC] Unbundle ext/interbase
G'day Lester Den fre. 22. mar. 2019 kl. 16.10 skrev Lester Caine : > It is not that we don't want to stand up and maintain it, it has been > impossible in recent years to get a handle on just what needs to be done > TO maintain it. The PDO extension is in a much worse state than the main > interbase one but both of them do their jobs as well as they can given > that in the case of PDO it can't handle the cross database transactions, > something that the main extension does quite happily. Like the previous 2-3 times we have had this topic going about removing the InterBase extension, you have referred to "we" (which I suppose is the PHP community as a whole), however time over and time again, no one has stepped up who has been able to maintain it. I thought about the PDO_Firebird extension too for removal, but I wanted to give the few possible PHP Firebird users a chance to evaluate the situation What do I mean by this? I mean that from a Core perspective (which I have explained before to you personally a few years ago), but to re-iterate: An extension in the Core that is not maintained, poses a risk of security and maintenance required to keep the extension to a level of quality that you (you as in the PHP community) deserve can therefore not be up to par. On top of that, it is a burden on us Core Developers that we cannot do anything to fix it. > Personally I've been wasting time recently trying to keep alive sites > that are using MySQL and the main problem with MySQL is the one thing > that Firebird does nicely. Backup just runs as a secondary cron job > independent of PHP while MySQL is reliant on PHP and current backups on > some wordpress powered sites are failing because they run out of time or > memory. I've never had a problem with loosing data with Firebird while > I've had recover MySQL situations a few times in the last year! That sounds like a bug in MySQL, which you should probably report to them or look at your configuration. > So all we are asking for is HELP with the code changes that result from > changes to the PHP API to keep this available. We asked for help in the past, many times in the fact if you search the archives (and you have taken apart of the conversation every single time), nothing has happened, therefore it is time to move past this. The extension will put in a repository at PECL, however it is unlike to retrieve further improvements or fixes from there unless someone actually steps up to take over it. We have done what we can to try call for help to keep this extension for as long as possible, but we can only do so much for so long. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Unbundle ext/interbase
On 22/03/2019 13:26, Kalle Sommer Nielsen wrote: G'day internals I'd like to start the discussion for the future of the ext/interbase extension: https://wiki.php.net/rfc/deprecate-and-remove-ext-interbase The rationale for pushing this extension out of the core is mentioned in the RFC. Unless there is any serious issues raised here, then I will put this into voting on Monday 8th of April, noon EET (which is a good two and a half weeks away). The intended voting period is set for 2 weeks, meaning if voting proceeds, the pools will be closed around Monday 22th of April, noon EET. It is not that we don't want to stand up and maintain it, it has been impossible in recent years to get a handle on just what needs to be done TO maintain it. The PDO extension is in a much worse state than the main interbase one but both of them do their jobs as well as they can given that in the case of PDO it can't handle the cross database transactions, something that the main extension does quite happily. Personally I've been wasting time recently trying to keep alive sites that are using MySQL and the main problem with MySQL is the one thing that Firebird does nicely. Backup just runs as a secondary cron job independent of PHP while MySQL is reliant on PHP and current backups on some wordpress powered sites are failing because they run out of time or memory. I've never had a problem with loosing data with Firebird while I've had recover MySQL situations a few times in the last year! So all we are asking for is HELP with the code changes that result from changes to the PHP API to keep this available. -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Unbundle ext/interbase
Morning Kalle, Seems like a reasonable plan, +1 Cheers Joe On Fri, 22 Mar 2019 at 14:26, Kalle Sommer Nielsen wrote: > G'day internals > > I'd like to start the discussion for the future of the ext/interbase > extension: > https://wiki.php.net/rfc/deprecate-and-remove-ext-interbase > > The rationale for pushing this extension out of the core is mentioned > in the RFC. > > Unless there is any serious issues raised here, then I will put this > into voting on Monday 8th of April, noon EET (which is a good two and > a half weeks away). The intended voting period is set for 2 weeks, > meaning if voting proceeds, the pools will be closed around Monday > 22th of April, noon EET. > > -- > regards, > > Kalle Sommer Nielsen > ka...@php.net > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
