Doctrine DBAL
  1. Doctrine DBAL
  2. DBAL-436

Logger should specify connection used in a master/slave situation

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Invalid
    • Affects Version/s: 2.3.2
    • Fix Version/s: 2.3.3
    • Component/s: None
    • Security Level: All
    • Labels:
      None

      Description

      Suppose there is a master connection with four slaves specified. Connections are being handled by the Doctrine\DBAL\Connections\MasterSlaveConnection class. Under the current implementation, all queries are logged under the "master" connection, even queries that are routed to the slaves by the Doctrine\DBAL\Connections\MasterSlaveConnection class.

      Since slave connections are separate, distinct connections, queries should be logged appropriately under their respective connections.

        Activity

        Jarrod Nettles created issue -
        Jarrod Nettles made changes -
        Field Original Value New Value
        Description Suppose there is a master connection with four slaves specified. Connections are being handled by the Doctrine\DBAL\Connections\MasterSlaveConnection class.

        Under the current implementation, all queries are logged under the "master" connection, even queries that are routed to the slaves by the Doctrine\DBAL\Connections\MasterSlaveConnection class.

        Since slave connections are separate, distinct connections, queries should be logged appropriately under their respective connections.
        Suppose there is a master connection with four slaves specified. Connections are being handled by the Doctrine\DBAL\Connections\MasterSlaveConnection class. Under the current implementation, all queries are logged under the "master" connection, even queries that are routed to the slaves by the Doctrine\DBAL\Connections\MasterSlaveConnection class.

        Since slave connections are separate, distinct connections, queries should be logged appropriately under their respective connections.
        Hide
        Benjamin Eberlei added a comment -

        Two reasons why this is not feasible:

        1. We actually don't ship loggers on our own, so if you want you can implement this yourself. We wouldn't have a way to "add" this, we only provide the interface.

        2. However the logger does not have access to the connection to find out which slave or master its currently using, you can create a logger that has a "setConnection($conn)" method and call this during bootstrapping the logger+connection.

        Show
        Benjamin Eberlei added a comment - Two reasons why this is not feasible: 1. We actually don't ship loggers on our own, so if you want you can implement this yourself. We wouldn't have a way to "add" this, we only provide the interface. 2. However the logger does not have access to the connection to find out which slave or master its currently using, you can create a logger that has a "setConnection($conn)" method and call this during bootstrapping the logger+connection.
        Benjamin Eberlei made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Invalid [ 6 ]

        This list may be incomplete, as errors occurred whilst retrieving source from linked applications:

        • Request to http://www.doctrine-project.org/fisheye/ failed: Error in remote call to 'FishEye 0 (http://www.doctrine-project.org/fisheye/)' (http://www.doctrine-project.org/fisheye) [AbstractRestCommand{path='/rest-service-fe/search-v1/crossRepositoryQuery', params={query=DBAL-436, expand=changesets[0:20].revisions[0:29],reviews}, methodType=GET}] : Received status code 503 (Service Temporarily Unavailable)

          People

          • Assignee:
            Benjamin Eberlei
            Reporter:
            Jarrod Nettles
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: