Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: Git Master
    • Fix Version/s: 2.5
    • Component/s: ORM
    • Labels:
      None

      Description

      Is there any particular reason why onFlush event is not triggered when the transaction is allready open? https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/UnitOfWork.php#L290 It would help a lot developing listeners since this event is the mostly used one and since theres preFlush now it seems a logical solution if onFlush would be a start of transaction in general

        Activity

        Gediminas Morkevicius created issue -
        Hide
        Benjamin Eberlei added a comment -

        onFluish is not the start of a transaction. It has nothing to do with this.

        Show
        Benjamin Eberlei added a comment - onFluish is not the start of a transaction. It has nothing to do with this.
        Benjamin Eberlei made changes -
        Field Original Value New Value
        Fix Version/s 2.3 [ 10185 ]
        Fix Version/s 2.2 [ 10157 ]
        Hide
        Marco Pivetta added a comment -

        Is a third event needed? Or is this to be marked as "won't fix"?

        Show
        Marco Pivetta added a comment - Is a third event needed? Or is this to be marked as "won't fix"?
        Hide
        Benjamin Eberlei added a comment -

        Maybe onBeginTransaction, onCommit and onRollback.

        However since you can start transactions manually using $em->beginTransaction(), the Flush events are somehwat independent of transactions anyways.

        Show
        Benjamin Eberlei added a comment - Maybe onBeginTransaction, onCommit and onRollback. However since you can start transactions manually using $em->beginTransaction(), the Flush events are somehwat independent of transactions anyways.
        Hide
        Gediminas Morkevicius added a comment -

        Well, user can start transaction anytime, but the fact is that if we think ORM we do not know nothing about the database. we just persist and flush objects.

        Yes I think these would be very useful, from how I see it, if you use event listeners, is:

        loadClassMetadata: you can apply extra mapping

        onFlush: you can modify entity changesets, or persist recalculate new ones, without triggering the database, since it is not used to begin the database modifications yet.

        onBeginTransaction: could use the database modifications keeping in sync the entity changesets. the thing about this event is that usually in behavioral way atomic updates are required. for example nestedset tree sync lft rgt columns, sortable sync the sort index, materialized path, all these requires atomic updates, and the best place is the start of transaction.

        onCommit: could be useful to execute right before commit, finalizing database modifications could be done.

        onRollback: this one is really something, since if you go far, there might be something like files uploaded during the entity processing, and you may want to remove them if transaction fails.

        Show
        Gediminas Morkevicius added a comment - Well, user can start transaction anytime, but the fact is that if we think ORM we do not know nothing about the database. we just persist and flush objects. Yes I think these would be very useful, from how I see it, if you use event listeners, is: loadClassMetadata: you can apply extra mapping onFlush: you can modify entity changesets, or persist recalculate new ones, without triggering the database, since it is not used to begin the database modifications yet. onBeginTransaction: could use the database modifications keeping in sync the entity changesets. the thing about this event is that usually in behavioral way atomic updates are required. for example nestedset tree sync lft rgt columns, sortable sync the sort index, materialized path, all these requires atomic updates, and the best place is the start of transaction. onCommit: could be useful to execute right before commit, finalizing database modifications could be done. onRollback: this one is really something, since if you go far, there might be something like files uploaded during the entity processing, and you may want to remove them if transaction fails.
        Hide
        Guilherme Blanco added a comment -

        This situation was barely documented here: http://www.doctrine-project.org/jira/browse/DDC-1443

        We need a better Transaction API that completely fixes the computation of changesets and also allow more fine grained control over Entities and their corresponding information.

        I'd postpone this one until 3.0.

        Show
        Guilherme Blanco added a comment - This situation was barely documented here: http://www.doctrine-project.org/jira/browse/DDC-1443 We need a better Transaction API that completely fixes the computation of changesets and also allow more fine grained control over Entities and their corresponding information. I'd postpone this one until 3.0.
        Benjamin Eberlei made changes -
        Workflow jira [ 13357 ] jira-feedback [ 14010 ]
        Benjamin Eberlei made changes -
        Workflow jira-feedback [ 14010 ] jira-feedback2 [ 15874 ]
        Benjamin Eberlei made changes -
        Workflow jira-feedback2 [ 15874 ] jira-feedback3 [ 18130 ]
        Benjamin Eberlei made changes -
        Fix Version/s 2.4 [ 10321 ]
        Fix Version/s 2.3 [ 10185 ]
        Benjamin Eberlei made changes -
        Fix Version/s 2.5 [ 10522 ]
        Fix Version/s 2.4 [ 10321 ]

        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=DDC-1599, expand=changesets[0:20].revisions[0:29],reviews}, methodType=GET}] : Received status code 503 (Service Temporarily Unavailable)

          People

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

            Dates

            • Created:
              Updated: