Question

Doctrine2, annotation driver. This seems to happen with composite keys.

A sample entity:

Generated PHP code:

use Doctrine\ORM\Mapping as ORM;

/**
 * @ORM\Entity
 * @ORM\Table(name="tags_to_tickets")
 */
class TagsToTickets
{
    /**
     * @ORM\Id
     * @ORM\Column(type="integer", options={"unsigned":true})
     */
    private $user_id;

    /**
     * @ORM\Id
     * @ORM\ManyToOne(targetEntity="Model\Entity\Ticket\Ticket", inversedBy="tagsToTickets")
     * @ORM\JoinColumn(name="ticket_id", referencedColumnName="id", nullable=false, onDelete="CASCADE")
     */
    private $ticket;

    /**
     * @ORM\Id
     * @ORM\ManyToOne(targetEntity="Model\Entity\Ticket\TicketTag", inversedBy="tagsToTickets")
     * @ORM\JoinColumn(name="tag_id", referencedColumnName="id", nullable=false, onDelete="RESTRICT")
     */
    private $ticketTags;
}

Now, if a table is created by doctrine orm:schema-tool:create based on such a file, the invalid order is reflected in the table definition:

I know (as stated in https://support.skipper18.com/2858/answered-configure-doctrine2-script-export-default-values?show=3843#c3843), that Skipper is not a PHP code generator but since it provides this particular feature, it should respect the declaration order of all fields (as far as no technical reason disallows it).

Comments

Thanks for the report.

I have to check it but I believe that the reason is that simple primary keys are always exported before foreign keys (even if they are also primary keys).

I can check if there will be a simple way how to fix it, but I'm afraid that composite foreign-key primary-keys are already so complicated in the export that there will be no room for such optimization.

---

Can you please send me your project to [email protected]?

It's sufficient to send only three mentioned entities. I would like to see exact configuration.

Thanks

---

Regular columns also always come before associations when exported. That's probably why you see user_id first and the foreign keys / associations after it. Plus, the order is only recognized for regular columns, associations have a "random" (-ly seeming) order when exported to PHP.

The export order is:
1. Regular columns
2. all OneToMany associations
3. all ManyToOne associations
4. ManyToMany associations

---

It's exactly like Jorn wrote. We're trying to keep order as possible but because there are several export components it's not always possible to export it in sync with visual order.

But this should not be a problem, because database order should be equal to Skipper order and only some order of annotations can be different.

---

I supposed there are quite a few scenarios which had to be covered. Today I run against an another one: embeddables...
The support in Skipper works like a charm. But now comes the issue, which Skipper cannot address.
Regardless of where the property for the embeddable is placed, doctrine orm:schema-tool:create seems to appends the columns resulting from it always at the end of the table (!).
So I guess there is no point in addressing this whole issue in Skipper if there seems to be no way to cover all of the cases, when at least one of them is caused by an external tool.

---

Thanks for sharing your experiences.

You're right, there are more of such issues. For example, when using SQLite database, there is no way how to reorder existing columns, etc.