Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:128798 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by lists.php.net (Postfix) with ESMTPS id B45B91A00BC for ; Thu, 9 Oct 2025 17:47:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1760032080; bh=/wiRfw58oslA4kWAvkh+AxMmTEHKXDPejp/cSTWx7ZY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=XGTwP5K7gIXCkoMDUUNGLVZijjcLw1l1Jo9Ot13LZli/rqL8iWLQssCcoWuKIif+8 qkRjRjRBH9RWTgz6UBtUeUV/IeXG6NedA1uVQxPFRnxVraOFVDYi0DMeppr2VUtCTR 1pSTYSiI7ExTeARhmKXfUpvPOlYB+n7/H0+nQePooButudy2tYtniUXufMUr2Rdw2u kiZUQ6j6pkYiZsk3kavNwZ4jAFE1nEUZyV5ivGUHcEMBLU+rgU+WH2GyATrUeIyC+t 2w2qckMARXLhkriaK+u0qXvJMgw2jw0mIB6d75QjFF9EPCYidMIdLJHkXW6olPVtsy AyaUbnej3+gew== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 03B311804C0 for ; Thu, 9 Oct 2025 17:47:56 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, T_SPF_TEMPERROR autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: No X-Envelope-From: Received: from mail-ed1-f51.google.com (mail-ed1-f51.google.com [209.85.208.51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 9 Oct 2025 17:47:55 +0000 (UTC) Received: by mail-ed1-f51.google.com with SMTP id 4fb4d7f45d1cf-6318855a83fso2613821a12.2 for ; Thu, 09 Oct 2025 10:47:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1760032068; x=1760636868; darn=lists.php.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=/wiRfw58oslA4kWAvkh+AxMmTEHKXDPejp/cSTWx7ZY=; b=S0FAFxlzLD4jOtKZ0c4/4sxklHSbF0HEj5PyRj13BdCOre7sw/cz3WCtdo7imEVmpm nJxZmqPqKhRQhaub4C+MnjcZWo7FDRcUP4hm1ToogK8XtSENeW4Lrq8U9Qxtd0+sdhMG HoNYkmKZ7b6jPvJpT9JHBXlsRVzobhK/8iIyTqZqZiZ3/2SG+4ZQYZ+fR1tSQW/WlnvC JD7R37r9nexFsmSPU4ceaTNvoQhii2FOugSI+EPBil6Hv1CicsmHWIhrLI5OlUfntFrO 6knaAp8vMkYS7Vbv6Y9sLOt9lxAZc3FXft/5dK5Ijzd6kkgI367BKLGATArEu7ad7pTQ oDnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1760032068; x=1760636868; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=/wiRfw58oslA4kWAvkh+AxMmTEHKXDPejp/cSTWx7ZY=; b=CQdgIkhSVVWGcjYRordRRJ9dCMPD7/tkfDobRM9OZxY7iV4rYc1Q6ppeV25ca3ea1F 0XcL9MbYse71IJcnzsM2Z3kLKHqnVbB9bMB40nT7ezHADICmMADRQe1r+DzJGSVoVAEr JuM3hg1EBRHAUc2cVtwr/M6IKaFEcMhn0saqmRtQbagN4QfyzRh9FmPcpirXPHyIBuXr tkYEZC7DOkvS2Bg5Hb3Vqb2mJfVCqIui5SL/P6uNJXuww82n9cf4t7qKMyQq7+yOKtfM TFz3caw4BhXOP2p951OQsnD2n4UG/J1iTRvoTQEEwOAP3JHxriBlba+SMwq2WX5XMIyr uSUg== X-Gm-Message-State: AOJu0YxkaRL/GEx7wCpVY7PGZIVMFYrVixGJ5cUVvZA2x6sucvK0m7Wh Lz7+RPOcVMMkgIyxXkqmRvQzLBlxRg6gEwO7jap4tdnTJRWvy89qMShN1J4iTQ7EjxW+JRVCwZ/ B5YBwWYH+wkagurxvAvSpRyLJ3lj5ZTljvIAW1YE= X-Gm-Gg: ASbGncu0GpXK9H7TxeSOIqp1AAIKddU2qeVDuwjE0kkV9Y80k7dWBYff3Iyq51Dx+pQ TGV5UDBjBYpcxGZgoSelGTHd7oKNyV1zSBw6RDy7SAtT3gOkxPOqJ5YiTKjAYgl5vua8W0Q5qLA 2WfbOICs0t8mDRCjHtcZ2YUZVtN+nN26mo0q1H8K8dm65SvvQYFIQtZyfFn0a3nQCi8wxRnmEvm FDQqSy86O3x0ZmmaOanGeRjJixODXoegbqFZjUhIQ== X-Google-Smtp-Source: AGHT+IF422nVBhZxIraQN0jXDQavVGr4Dso0VA2FbNhKCwffsPnne5fvUkbS291tUcyvcp2YzZkAvBxxDtPv0/Gs1lQ= X-Received: by 2002:a05:6402:27cd:b0:63a:35c:6ec4 with SMTP id 4fb4d7f45d1cf-63a035c73cemr2197983a12.21.1760032067939; Thu, 09 Oct 2025 10:47:47 -0700 (PDT) Precedence: list list-help: list-post: List-Id: x-ms-reactions: disallow MIME-Version: 1.0 References: <43a60bc9-8e3d-4d83-ae8a-13465a6ef3e9@beccati.com> In-Reply-To: <43a60bc9-8e3d-4d83-ae8a-13465a6ef3e9@beccati.com> Date: Thu, 9 Oct 2025 13:47:35 -0400 X-Gm-Features: AS18NWDM2oSvSnmdV-cgwgs1vIFQceOmoEmeC_d8ppV04_0QEmh_SUhBR-lSgfI Message-ID: Subject: Re: [PHP-DEV] [Discuss] Add PDO disconnect() and isConnected() To: Matteo Beccati Cc: PHP internals Content-Type: multipart/alternative; boundary="00000000000033f3580640bd664f" From: rposky@gmail.com (Robert Wolf) --00000000000033f3580640bd664f Content-Type: text/plain; charset="UTF-8" > I would argue we should discourage their use > (deprecation is my dream!) I am with you on the deprecation of persistent connections, as the implementation is awkward, but not without addressing the use case. > As you well know, PDO is an object which also optionally uses PHP persistent resources to facilitate connection re-use across PHP requests, a feature which I don't believe has a parallel in object space. Perhaps > > therein lies a feature request, i.e. to allow an object to be made persistent in the same way a resource can. I floated the above idea. Any inclination that would be worth pursuing? > ... would be an interface to declare the persistent connection as defunct, such that upon subsequent PDO creation, a new connection will be formed, and the former will be closed. This is distinct from a disconnect or > reconnect procedure, and similar to failing a "liveness" check upon persistent PDO creation. Users could then effectively replace their persistent PDO in the same manner they would do so for a "regular" PDO. This idea is growing on me, to address the issue of a defunct persistent connection, rather than the disconnect() interface. Any thoughts on introducing a new attribute to the PDO constructor to prompt the reconnection: PDO::ATTR_PERSISTENT_RECONNECT. -Robert --00000000000033f3580640bd664f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> I would argue we should discourage t= heir use=C2=A0
>= (deprecation is my dream!)

I am= with you on the deprecation of persistent connections, as the implementati= on is awkward, but not without addressing the use case.=C2=A0

> As you well know, PDO is an ob= ject which also optionally uses PHP persistent resources to facilitate conn= ection re-use across PHP requests, a feature which I don't believe has = a parallel in object space. Perhaps > > therein lies a feature reques= t, i.e. to allow an object to be made persistent in the same way a resource= can.

I floated the above idea. Any inclination that wou= ld be worth pursuing?

> ... would be an interfa= ce to declare the persistent connection as defunct, such that upon subseque= nt PDO creation, a new connection will be formed, and the former will be cl= osed. This is distinct from a disconnect or > reconnect procedure, and s= imilar to failing a "liveness" check upon persistent PDO creation= . Users could then effectively replace their persistent PDO in the same man= ner they would do so for a "regular" PDO.

This idea is growing on me, to address the issue of a defunct persistent = connection, rather than the disconnect() interface. Any thoughts on introdu= cing a new attribute to the PDO constructor to prompt the reconnection: PDO= ::ATTR_PERSISTENT_RECONNECT.

-Robert
--00000000000033f3580640bd664f--