doctrine/archived-orm
1
0
Fork 0
mirror of https://github.com/doctrine/orm.git synced 2026-04-27 00:18:04 +02:00
Code Issues 5.3k Packages Projects Releases 100 Wiki Activity

A Native Sql is committing the current transaction #5643

New Issue
Closed
opened 2026-01-22 15:13:36 +01:00 by admin · 8 comments
admin commented 2026-01-22 15:13:36 +01:00
Owner
Copy Link
Copy Source

Originally created by @JodyLognoul on GitHub (Aug 16, 2017).

Originally assigned to: @lcobucci on GitHub.

Hello Doctrine,

Is there a way to execute a native sql query (calling a stored procedure) without auto commiting the current open transaction?

Example:


$entityManager->beginTransaction();
...
$entityManager->merge($event);
$entityManager->flush();
...
$sql = <<<SQL
    CALL eventsForPeriod_EventList();
SQL;

$all = $this->em->getConnection()->fetchAll($sql);
// => at this point the transaction is commited :/
...
$entityManager->rollback();

Thank you !

Jody

Originally created by @JodyLognoul on GitHub (Aug 16, 2017). Originally assigned to: @lcobucci on GitHub. Hello Doctrine, Is there a way to execute a native sql query (calling a stored procedure) without auto commiting the current open transaction? Example: ```php $entityManager->beginTransaction(); ... $entityManager->merge($event); $entityManager->flush(); ... $sql = <<<SQL CALL eventsForPeriod_EventList(); SQL; $all = $this->em->getConnection()->fetchAll($sql); // => at this point the transaction is commited :/ ... $entityManager->rollback(); ``` Thank you ! Jody
admin added the BugInvalidMissing Tests labels 2026-01-22 15:13:36 +01:00
admin closed this issue 2026-01-22 15:13:36 +01:00
admin commented 2026-01-22 15:13:36 +01:00
Author
Owner
Copy Link
Copy Source

@Ocramius commented on GitHub (Aug 16, 2017):

Only the inner transaction should be committed there: the outer one is still active. You can check the transaction nesting level on the connection.

@Ocramius commented on GitHub (Aug 16, 2017): Only the inner transaction should be committed there: the outer one is still active. You can check the transaction nesting level on the connection.
admin commented 2026-01-22 15:13:39 +01:00
Author
Owner
Copy Link
Copy Source

@JodyLognoul commented on GitHub (Aug 16, 2017):

You're right, the nesting level is at 1 when the $entityManager->rollback(); will be done.

But, I don't know why, my data are persisted after the fetchAll() :-/ If I comment the line, there are not!

Any idea?

Thank you for your fast response.

@JodyLognoul commented on GitHub (Aug 16, 2017): You're right, the nesting level is at 1 when the `$entityManager->rollback();` will be done. But, I don't know why, my data are persisted after the fetchAll() :-/ If I comment the line, there are not! Any idea? Thank you for your fast response.
admin commented 2026-01-22 15:13:39 +01:00
Author
Owner
Copy Link
Copy Source

@Ocramius commented on GitHub (Aug 16, 2017):

On MySQL, transaction nesting is emulated via savepoints: I think we need
more integration tests for MySQL to see if it actually behaves like that
correctly or if more flags/server-side settings are needed. Also check that
you aren't running on MyISAM, which is just a wreckage.

On 16 Aug 2017 4:28 PM, "Jody Lognoul" notifications@github.com wrote:

You're right, the nesting level is at 1 when the $entityManager->rollback();
will be done.

But, I don't know why, my data are persisted after the fetchAll() :-/ If I
comment the line, it is not!

Any idea?

Thank you for your fast response.

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
https://github.com/doctrine/doctrine2/issues/6628#issuecomment-322789445,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJakMUjvPjh9DjbTMNBnbQZVREbmrd5ks5sYvx_gaJpZM4O4-tJ
.

@Ocramius commented on GitHub (Aug 16, 2017): On MySQL, transaction nesting is emulated via savepoints: I think we need more integration tests for MySQL to see if it actually behaves like that correctly or if more flags/server-side settings are needed. Also check that you aren't running on MyISAM, which is just a wreckage. On 16 Aug 2017 4:28 PM, "Jody Lognoul" <notifications@github.com> wrote: You're right, the nesting level is at 1 when the $entityManager->rollback(); will be done. But, I don't know why, my data are persisted after the fetchAll() :-/ If I comment the line, it is not! Any idea? Thank you for your fast response. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <https://github.com/doctrine/doctrine2/issues/6628#issuecomment-322789445>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJakMUjvPjh9DjbTMNBnbQZVREbmrd5ks5sYvx_gaJpZM4O4-tJ> .
admin commented 2026-01-22 15:13:39 +01:00
Author
Owner
Copy Link
Copy Source

@JodyLognoul commented on GitHub (Oct 4, 2017):

Hello,

I finally found that the commit was being caused due to a coding error in my stored procedure... Before the creation of the temporary Table, I was issuing a Drop Table statement, without the TEMPORARY keyword, which was causing an auto-commit.

https://dev.mysql.com/doc/refman/5.7/en/implicit-commit.html

So, the issue wasn't Doctrine wise, sorry about that.

Thanks btw.

@JodyLognoul commented on GitHub (Oct 4, 2017): Hello, I finally found that the commit was being caused due to a coding error in my stored procedure... Before the creation of the temporary Table, I was issuing a Drop Table statement, without the **TEMPORARY** keyword, which was causing an auto-commit. https://dev.mysql.com/doc/refman/5.7/en/implicit-commit.html So, the issue wasn't Doctrine wise, sorry about that. Thanks btw.
admin commented 2026-01-22 15:13:39 +01:00
Author
Owner
Copy Link
Copy Source

@Ocramius commented on GitHub (Oct 4, 2017):

Argh, yes, MySQL still doesn't have transactional DDL, but Doctrine DOES create temporary tables for some ManyToMany operations, and that's not fixable.

@Ocramius commented on GitHub (Oct 4, 2017): Argh, yes, MySQL still doesn't have transactional DDL, but Doctrine DOES create temporary tables for some ManyToMany operations, and that's not fixable.
admin commented 2026-01-22 15:13:40 +01:00
Author
Owner
Copy Link
Copy Source

@lcobucci commented on GitHub (Nov 24, 2017):

@Narcotic should we close this?

@lcobucci commented on GitHub (Nov 24, 2017): @Narcotic should we close this?
admin commented 2026-01-22 15:13:40 +01:00
Author
Owner
Copy Link
Copy Source

@JodyLognoul commented on GitHub (Nov 24, 2017):

Yes!

@JodyLognoul commented on GitHub (Nov 24, 2017): Yes!
admin commented 2026-01-22 15:13:41 +01:00
Author
Owner
Copy Link
Copy Source

@lcobucci commented on GitHub (Nov 24, 2017):

Closing as invalid since it's not an ORM issue.

@lcobucci commented on GitHub (Nov 24, 2017): Closing as `invalid` since it's not an ORM issue.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
BC Break
Bug
Can't Fix
Deprecation
Documentation
DQL
Duplicate
Failing Test
Hacktoberfest
Improvement
Improvement
Incomplete
Invalid
Missing Tests
New Feature
PR Created
pull-request
Mirrored from GitHub Pull Request
 Question
Regression
Status: Waiting feedback
Waiting feedback
WIP
Won't Fix
No Label Bug Invalid Missing Tests
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
admin
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: doctrine/archived-orm#5643
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?