-
Notifications
You must be signed in to change notification settings - Fork 100
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for PHP 8.4 #228
Comments
It seems reasonable and appropriate to me. cc/ @pmjones @harikt @frederikbosch |
Boooom.. @srjlewis Thank you for bringing this up and also nice pointers. We can make this next major version, but I am not sure what should we call this. I don't like the name Some of the methods came to my mind are |
PR #229 |
@harikt I do agree with the naming, I used autoConnect as an example, and can easily be changed, apart from this issue I have not run into any other issues with PHP 8.4 |
With driver specific subclasses in PHP, I think we should re-evaluate more than just the new If so, would it then not be better to drop < 8.4 for a new version 6.0? And just use override the <?php
class ExtendedPdo
{
public const CONNECT_IMMEDIATELY = 'immediate';
protected array $args = [];
protected bool $driverSpecific = false;
public function __construct(
string $dsn,
?string $username = null,
?string $password = null,
array $options = [],
array $queries = [],
?ProfilerInterface $profiler = null
) {
// if no error mode is specified, use exceptions
if (! isset($options[PDO::ATTR_ERRMODE])) {
$options[PDO::ATTR_ERRMODE] = PDO::ERRMODE_EXCEPTION;
}
// retain the arguments for later
$this->args = [
$dsn,
$username,
$password,
$options,
$queries
];
if ($options[self::CONNECT_IMMEDIATELY]) {
$this->establishConnection();
}
// keep the rest of the constructor
}
#[\Override]
public static function connect(string $dsn, string $username = null, string $password = null, array $options = null) {
{
$pdo = new self($dsn, $username, $password, $options);
$pdo->driverSpecific = true;
return $pdo;
}
// call this method from query, perform, execute etc
private function establishConnection(): void
{
if ($this->pdo) {
return;
}
if ($this->driverSpecific) {
$this->pdo = PDO::connect($dsn, $username, $password, $options);$password, $options);
} else {
$this->pdo = new PDO($dsn, $username,
}
}
} |
@frederikbosch we could approch the issue has you mention, but I see a few issues in your approach.
but by all means keep the ideas flowing |
|
It will help with a smooth migration/update path We can release v6.0 and users can implement it before the release of PHP 8.4 This would also allow users to run PHP 8.x in production and do testing with PHP 8.4 before its release. This is what I am doing at the moment, yes I know users can use some composer magic but that makes it more complicated for the users. I also think it is a good idea to keep compatability with all supported version of PHP and not make users switch between versions of the libaray. |
I disagree with that.
Moreover, that is why there is semantic versioning: it's a contract how to deal with backward compatibility. When, you change the major version, you are going to break things. Now, with PHP 8.4 compatibility will be broken anyhow since the new connect method will force us to break things. You can better re-evaluate, and put the library in a mode that is going to proof itself again in the future. Hence, I suggest we slow down, and evaluate whether we need the driver specific parsers included in this library now PHP provides them in the core of PDO. And then see what is the best syntactic solution for immediate or manual connections. |
Hi Could we move forward with any ideas for the support for PHP 8.4 as there is now only 10 days to the GA release of PHP 8.4 I dont mind if you want to implement the 8.4 support in a different way, I just think time is catching up quickly. |
Hi Thank you all for your insightful discussions. I can see valid points in both approaches. The clean v6 design proposed by @frederikbosch is ideal for applications that depend on a single PHP version. However, when libraries need to support both PHP 8.3 and PHP 8.4, some abstraction is necessary. In such cases, I believe implementing this abstraction at Aura.Sql's layer would be more appropriate than pushing it up to higher layers. May I suggest the following approach: For v5: Introduce a new internal method For v6: Since we can break BC, we can simply use the native PDO implementation targeting PHP 8.4+ only, without any abstraction. I chose the name |
@koriym I don´t get your suggested approach completely. Could you elaborate what you want to do in v5? What do we gain with this new As stated before, I am all for targeting 8.4 only for v6. It is not us that is breaking BC, it is PHP that is doing that (and rightfully so). Do I understand correctly that is what you are suggesting? |
v5: /** This method is added, and nothing else changes. */
public function establishConnection(): void
{
if ($this->pdo) {
return;
}
// connect
$this->profiler->start(__FUNCTION__);
list($dsn, $username, $password, $options, $queries) = $this->args;
if(version_compare(phpversion(), '8.4.0', '<')) {
$this->pdo = new PDO($dsn, $username, $password, $options);
} else {
$this->pdo = PDO::connect($dsn, $username, $password, $options);
}
$this->profiler->finish();
// connection-time queries
foreach ($queries as $query) {
$this->exec($query);
}
} What we can gain from this method: Libraries that must support both PHP 8.3 and PHP 8.4 can be made compatible with both PHP versions by modifying them to call this method. v6:
Yes. Hope this makes things clear. |
I dont think it is worth changing v5, as the connect() signature is totally different v5 public function connect(): void v6 and pdo in php 8.4 onwards public static function connect(string $dsn [, string $username [, string $password [, array $options ]]]) so just including What I was trying to do in version v6 was change the So all version of PHP would be able to use v6 and PHP <= 8.3 would be able to use the new PDO connect syntax due to the changed public static function connect(
string $dsn,
?string $username = null,
?string $password = null,
?array $options = [],
array $queries = [],
?ProfilerInterface $profiler = null
): static {
$pdo = new static($dsn, $username, $password, $options ?? [], $queries, $profiler);
$pdo->establishConnection();
return $pdo;
} I dont mind making v6 compatable with PHP 8.4 above I would only need to change public function establishConnection(): void
{
if ($this->pdo) {
return;
}
// connect
$this->profiler->start(__FUNCTION__);
list($dsn, $username, $password, $options, $queries) = $this->args;
$this->pdo = PDO::connect($dsn, $username, $password, $options);
$this->profiler->finish();
// connection-time queries
foreach ($queries as $query) {
$this->exec($query);
}
} I have updated the git actions to include PHP 8.4 in testing and all versions of PHP pass |
I would do the latter and on-top I really believe we need to investigate how our parsers. What use do they still have? |
Look at this commit in php-src, that is pretty much what we are offering with our parsers. |
Why don't we merge the proposed code (after review) of @srjlewis, tag v6 beta 1, let people use that if they want to use PHP 8.4 from today? Investigate the parsers, change the code where necessary and then move towards v6-rc.1 and finally v6.0? |
@frederikbosch I do aggree they need looking at, I was/am aming for compatability first of all and as we move forward, and the userbase move to newer versions of PHP I totally agree, with reviewing and removing the parsers. |
@frederikbosch I have done the update requested, and added a test for the |
I apologize for my earlier confusion. You are right - this is about the method name conflict between Aura.Sql's connect() and PHP 8.4's PDO::connect(). That's why we need v6 for PHP 8.4 support. Thank you for the clarification. |
I was thinking of @harikt point of putting a public function establishConnection(): void
{
$this->connect();
} This would allow users to switch to the |
@srjlewis We can add a method as you suggested and promote it in 5x, so people using older versions can use it. That is just a ux I believe, so easier to switch from 5.x to 6.x. |
I have merged #229 to 6.x . |
Hi
I am doing some eairly testing with PHP 8.4
I have found a conflict within the library
It is a result of a accepted PHP RFC https://wiki.php.net/rfc/pdo_driver_specific_subclasses which introduces a static connect method PDO::connect() as shown in the above method.
Here is lavavel's fix within there library https://github.com/laravel/framework/pull/52538/files
It looks like
ExtendedPdoInterface::connect()
would need renaming to somthing along the lines ofExtendedPdoInterface::autoConnect()
and throughout the rest of the library.I would then think
ExtendedPdo:autoConnect()
would looke somthing like.This would need to be a new majer version due to the big BC break
ExtendedPdoInterface::connect()
being public.I can create a MR for this if needed.
The text was updated successfully, but these errors were encountered: