Add microseconds support on datetime/time types #5580

New Issue

admin · 2026-01-22T15:11:50+01:00

admin commented

2026-01-22 15:11:50 +01:00

Originally created by @Khodl on GitHub (Jun 19, 2017).

Originally assigned to: @Ocramius on GitHub.

First of all, sorry if this has already been reported, but I already checked for 3 days a solution without succeeding.

Here is my situation:

I implement a parent class, GenericMessage

 * Message
 *
 * @ORM\Table(name="message")
 * @ORM\Entity(repositoryClass="AppBundle\Repository\MessageRepository")
 * @ORM\InheritanceType("JOINED")
 * @ORM\DiscriminatorColumn(name="message_type", type="string")
 * @ORM\DiscriminatorMap({
 *      "gallery" = "GalleryMessage",
 *      "text" = "TextMessage",
 * })
 */
abstract class GenericMessage {
...

with (at least) two children:

/**
 * GalleryMessage
 *
 * @ORM\Table(name="message_gallery")
 * @ORM\Entity()
 */
class GalleryMessage extends GenericMessage
{

and

/**
 * TextMessage
 *
 * @ORM\Table(name="message_text")
 * @ORM\Entity()
 */
class TextMessage extends GenericMessage
{

Then I insert create different instances of these two messages:

$t1 = new TextMessage();
$g1 = new GalleryMessage();
$t2 = new TextMessage();

$em->persist($t1);
$em->persist($g1);
$em->persist($t2);
$em->flush();

However, the id are not in the right order, as inserts are nested by entity by the UnitOfWork, if I understood the code well.

Therefore, if we sort by id, we would get $t1, $t2, $g1 instead of $t1, $g1, $t2.

Inserts order are:

GenericMessage --> get id (for instance 4)
TextMessage -> insert with id 4
GenericMessage --> get id (for instance 5)
TextMessage -> insert with id 5
GenericMessage --> get id (for instance 6)
GalleryMessage -> insert with id 6

Is there any way to make all the insertions in the right order? For instance insert all the GenericMessage rows, then collect the ids, and the the order doesn't matter?

For instance:

GenericMessage --> get id (for instance 4)
GenericMessage --> get id (for instance 5)
GenericMessage --> get id (for instance 6)
TextMessage -> insert with id 4
TextMessage -> insert with id 6
GalleryMessage -> insert with id 5

Originally created by @Khodl on GitHub (Jun 19, 2017). Originally assigned to: @Ocramius on GitHub. First of all, sorry if this has already been reported, but I already checked for 3 days a solution without succeeding. Here is my situation: I implement a parent class, GenericMessage ```/** * Message * * @ORM\Table(name="message") * @ORM\Entity(repositoryClass="AppBundle\Repository\MessageRepository") * @ORM\InheritanceType("JOINED") * @ORM\DiscriminatorColumn(name="message_type", type="string") * @ORM\DiscriminatorMap({ * "gallery" = "GalleryMessage", * "text" = "TextMessage", * }) */ abstract class GenericMessage { ... ``` with (at least) two children: ``` /** * GalleryMessage * * @ORM\Table(name="message_gallery") * @ORM\Entity() */ class GalleryMessage extends GenericMessage { ``` and ``` /** * TextMessage * * @ORM\Table(name="message_text") * @ORM\Entity() */ class TextMessage extends GenericMessage { ``` Then I insert create different instances of these two messages: ``` $t1 = new TextMessage(); $g1 = new GalleryMessage(); $t2 = new TextMessage(); $em->persist($t1); $em->persist($g1); $em->persist($t2); $em->flush(); ``` However, the id are not in the right order, as inserts are nested by entity by the UnitOfWork, if I understood the code well. Therefore, if we sort by id, we would get `$t1`, `$t2`, `$g1` instead of `$t1`, `$g1`, `$t2`. Inserts order are: 1. GenericMessage --> get id (for instance 4) 1. TextMessage -> insert with id 4 1. GenericMessage --> get id (for instance 5) 1. TextMessage -> insert with id 5 1. GenericMessage --> get id (for instance 6) 1. GalleryMessage -> insert with id 6 Is there any way to make all the insertions in the right order? For instance insert all the GenericMessage rows, then collect the ids, and the the order doesn't matter? For instance: 1. GenericMessage --> get id (for instance 4) 1. GenericMessage --> get id (for instance 5) 1. GenericMessage --> get id (for instance 6) 1. TextMessage -> insert with id 4 1. TextMessage -> insert with id 6 1. GalleryMessage -> insert with id 5

admin added the Improvement Duplicate labels 2026-01-22 15:11:50 +01:00

admin closed this issue

2026-01-22 15:11:51 +01:00

admin commented

2026-01-22 15:11:52 +01:00

@lcobucci commented on GitHub (Jun 20, 2017):

@Khodl the order of the statements will not necessarily match with the order of $em->persist() calls, it's calculated based on several things (specially dependencies). However the ORM will process things entity by entity (not table).

I don't understand why this is a problem for you though... I mean, why the ID/order is so important to you?

@lcobucci commented on GitHub (Jun 20, 2017): @Khodl the order of the statements will not necessarily match with the order of `$em->persist()` calls, it's calculated based on several things (specially dependencies). However the ORM will process things entity by entity (not table). I don't understand why this is a problem for you though... I mean, why the ID/order is so important to you?

admin commented

2026-01-22 15:11:53 +01:00

@Khodl commented on GitHub (Jun 20, 2017):

Yes I noticed that when checked Doctrine's code to see how it works. While I can totally understand why dependencies are required and impact the order, I don't get why nesting by entity couldn't be avoided (except maybe in case Doctrine sometimes inserts multiple values in one query).

My reason: I want to use my ID to sort my entities (Message) later. It's especially a problem as MySQL doesn't support microseconds precision (see issue #6305). My only solution would be to add a third field, with the timestamp as a number, formatted "U.u", but it would add one more index. Any other idea?

@Khodl commented on GitHub (Jun 20, 2017): Yes I noticed that when checked Doctrine's code to see how it works. While I can totally understand why dependencies are required and impact the order, I don't get why nesting by entity couldn't be avoided (except maybe in case Doctrine sometimes inserts multiple values in one query). My reason: I want to use my ID to sort my entities (Message) later. It's especially a problem as MySQL doesn't support microseconds precision (see issue #6305). My only solution would be to add a third field, with the timestamp as a number, formatted "U.u", but it would add one more index. Any other idea?

admin commented

2026-01-22 15:11:55 +01:00

@lcobucci commented on GitHub (Jun 20, 2017):

except maybe in case Doctrine sometimes inserts multiple values in one query

That's an improvement that we're planning to implement in the near future (3.x).

Any other idea?

Not really, unfortunately MySQL 5.7 support is not 100% yet... I wouldn't rely on an auto-incremented id if you need that level of precision though (specially because it would reflect the moment where the object got persisted and not really the moment it was created/edited).

@lcobucci commented on GitHub (Jun 20, 2017): > except maybe in case Doctrine sometimes inserts multiple values in one query That's an improvement that we're planning to implement in the near future (3.x). > Any other idea? Not really, unfortunately MySQL 5.7 support is not 100% yet... I wouldn't rely on an auto-incremented id if you need that level of precision though (specially because it would reflect the moment where the object got persisted and not really the moment it was created/edited).

admin commented

2026-01-22 15:11:55 +01:00

@Khodl commented on GitHub (Jun 20, 2017):

I see. Also, it totally makes sense in case I need to switch to another db that doesn't use incremental ids.

About 3.x roadmap, do you think it will support MySQL 5.7 (or at least precision)? And do you have any estimation of the deadline?

Thanks for your time!

@Khodl commented on GitHub (Jun 20, 2017): I see. Also, it totally makes sense in case I need to switch to another db that doesn't use incremental ids. About 3.x roadmap, do you think it will support MySQL 5.7 (or at least precision)? And do you have any estimation of the deadline? Thanks for your time!

admin commented

2026-01-22 15:11:56 +01:00

@lcobucci commented on GitHub (Jun 20, 2017):

We're trying to get MySQL 5.7 compatibility to 2.6 but we can always get more help if you're willing to send your contribution. No idea in terms of deadline, we're still organising the release https://github.com/doctrine/doctrine2/milestone/2

@lcobucci commented on GitHub (Jun 20, 2017): We're trying to get MySQL 5.7 compatibility to 2.6 but we can always get more help if you're willing to send your contribution. No idea in terms of deadline, we're still organising the release https://github.com/doctrine/doctrine2/milestone/2

admin commented

2026-01-22 15:11:56 +01:00

@lcobucci commented on GitHub (Jun 23, 2017):

@Ocramius should we add this to 2.6 as well (store microseconds)... it can be added to other platforms as well (PostgreSQL supports it seems we don't use it - 638cb41b85/lib/Doctrine/DBAL/Platforms/PostgreSqlPlatform.php (L1058)).

It should be done on DBAL though.

@lcobucci commented on GitHub (Jun 23, 2017): @Ocramius should we add this to `2.6` as well (store microseconds)... it can be added to other platforms as well (PostgreSQL supports it seems we don't use it - https://github.com/doctrine/dbal/blob/638cb41b859d22007218bbb32b742f1a41f133a2/lib/Doctrine/DBAL/Platforms/PostgreSqlPlatform.php#L1058). It should be done on DBAL though.

admin commented

2026-01-22 15:11:56 +01:00

@lcobucci commented on GitHub (Oct 1, 2017):

@Ocramius I've opened an issue on DBAL regarding this but will keep it on the ORM too, since I don't know it will require any change on this side too (mapping idk).

@lcobucci commented on GitHub (Oct 1, 2017): @Ocramius I've opened an issue on DBAL regarding this but will keep it on the ORM too, since I don't know it will require any change on this side too (mapping idk).

admin commented

2026-01-22 15:11:57 +01:00

@lcobucci commented on GitHub (Oct 1, 2017):

Not sure if this should be part of ORM 2.6 though 😄

@lcobucci commented on GitHub (Oct 1, 2017): Not sure if this should be part of ORM 2.6 though 😄

admin commented

2026-01-22 15:11:57 +01:00

@pathmissing commented on GitHub (Jan 12, 2018):

Hi, are there any updates on this issue?
Regards

@pathmissing commented on GitHub (Jan 12, 2018): Hi, are there any updates on this issue? Regards

admin commented

2026-01-22 15:11:58 +01:00