Doctrine DBAL
  1. Doctrine DBAL
  2. DBAL-38

Unused DBAL\Events (preExecute, postExecute)...

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 2.0.0-BETA3
    • Fix Version/s: 2.0.0-BETA4
    • Component/s: None
    • Labels:
      None
    • Environment:
      Linux

      Description

      The ORM has a neat collection of Events, but the DBAL doesn't have any.
      There is an DBAL/Events.php class which has defined constants for preExec, postExec, preExecute and postExecute (similar to ORM/Events.php), but these seem to be completely unused.
      The only event/loging seems to be the ->logSql() event.

      A preExecute & postExecute events would be great for timing/profiling queries.

        Activity

        Hide
        Benjamin Eberlei added a comment -

        Removed!

        Show
        Benjamin Eberlei added a comment - Removed!
        Hide
        Roman S. Borschel added a comment -

        I think they can be removed as the DBAL SQLLogger now also records the execution time.

        Show
        Roman S. Borschel added a comment - I think they can be removed as the DBAL SQLLogger now also records the execution time.
        Hide
        Christian Heinrich added a comment -

        Has any decision been made on whether to remove or not?

        Show
        Christian Heinrich added a comment - Has any decision been made on whether to remove or not?
        Hide
        Christian Heinrich added a comment -

        If there are no other use cases, +1 for removal.

        Show
        Christian Heinrich added a comment - If there are no other use cases, +1 for removal.
        Hide
        Roman S. Borschel added a comment -

        Personally I find timing queries in php code not very useful since its very inaccurate and you dont get any further information.

        Show
        Roman S. Borschel added a comment - Personally I find timing queries in php code not very useful since its very inaccurate and you dont get any further information.
        Hide
        Benjamin Eberlei added a comment -

        Hm timing and profiling could either be done with vendor-tools or we extend the SqlLogger interface a bit like i proposed in a previous issue. I dont see any other use-cases.

        Show
        Benjamin Eberlei added a comment - Hm timing and profiling could either be done with vendor-tools or we extend the SqlLogger interface a bit like i proposed in a previous issue. I dont see any other use-cases.
        Hide
        Roman S. Borschel added a comment -

        I'm not sure of their usefulness. Hannes mentions timing queries but this is not really possible since many queries are not executed through execute()/executeUpdate() but rather through prepare() and then execute() on the Statement.

        Are there any other good use-cases?

        Show
        Roman S. Borschel added a comment - I'm not sure of their usefulness. Hannes mentions timing queries but this is not really possible since many queries are not executed through execute()/executeUpdate() but rather through prepare() and then execute() on the Statement. Are there any other good use-cases?
        Hide
        Jonathan H. Wage added a comment -

        Roman, do we want to implement these? If so I can produce a patch.

        Show
        Jonathan H. Wage added a comment - Roman, do we want to implement these? If so I can produce a patch.

          People

          • Assignee:
            Benjamin Eberlei
            Reporter:
            Hannes Magnusson
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: