[Closed] Gedmo Timestampable: yaml issues in new version

Question

Hello,

yesterday we've upgraded Skipper to new version and since then we have issue with Gedmo Timestampable configuration. Whenever we use Skipper to generate Yaml configuration files it outputs:

created:
  type: datetime
  nullable: false
  gedmo:
    - timestampable:
        on: create

Which is not recognized by timestampable extension. When i change to following it works fine:

created:
  type: datetime
  nullable: false
  gedmo:
    timestampable:
      on: create

I'd appreciate support regarding this issue.

Comments

This is real madness. Yes, we updated it because of this ticket https://support.skipper18.com/2531/fixed-gedmo-tree-generates-incorrect-yml-arrays

It seems that some properties need to be as array and some as child nodes. It's very frustrating. Whole Gedmo Yaml parser has very bad architecture.

---

Thank you for quick answer. They're inconsistent indeed. For timestampable there are child nodes: https://github.com/Atlantic18/DoctrineExtensions/blob/master/doc/timestampable.md .

Meanwhile i'm gonna use XML format instead.

Answer 1

To be able to fix it correctly, I would need to know what is a correct for to write these two following definitions together

created:
  type: datetime
  nullable: false
  gedmo:
    timestampable:
       on: create

and this one

lft:
  type: integer
  gedmo:
    - treeLeft

when sometime it's necessary to generate it without "-" and sometime with "-". So what is expected form when both of these have to be exported? Something like this?

created:
  type: datetime
  nullable: false
 gedmo:
    timestampable:
       on: create
    - treeLeft

I believe it's not. Can you please check it for me and let me know? Thanks

Comments

In my understanding it seems impossible to use timestampable with tree on same field (at least in yaml). I'm not familiar with tree extension, so i don't know if it would make sense to use these two together.

I don't think such notation would be valid:

 gedmo:
    timestampable:
       on: create
    - treeLeft

---

These two behaviors were only example of this inconsistency. The problem is that there are more such situations and we're not able to implement it because of these conflicts.

Using of different format XML/Annotation is definitely a good idea (and from what I know Yml format will be probably abandoned completely for Doctrine3)

---

I opened the initial issue that Ludek linked to in the original comments where there were issues with Gedmo Tree. I found this issue after trying the new version, which has broken both the Tree and Timestampable extensions.

Timestampable is broken for the reasons that have been outlined, and Tree is broken due to an array being used for the primary tree declaration, e.g.:

gedmo:
  - tree:
      type: nested

This should be formatted as is previously was, as per here: https://github.com/Atlantic18/DoctrineExtensions/blob/v2.4.x/doc/tree.md#yaml-mapping-example

The inconsistencies are, as you say, madness, however I can't see them changing any time soon. Also, as has also been seen, you can't combine these on a field and output valid YAML.

Would it be possible to format the various fields correctly, with the knowledge (or a warning) that they can't be used together?

I can't think of any reason why you would have a field that's both timestampable and a tree attribute, in fact I don't think it's even possible based on the required field types.

• treeLeft, treeRight and treeLevel must be integers
• treeRoot and treeParent are self-referencing relationships (FKs)

This obviously isn't considering the other extensions, however I think the same argument stands, which is that these fields are used specifically for tree functionality.

I appreciate that it isn't this simple when creating software that should be able to handle any user input, however I can't see any other option.

---

Thanks for detailed reply.

Although I understand that in this specific use case it's not possible to use both behaviors there can be another combinations which are allowed but not possible to define because of this non-determinant form of yaml definition (and as programmer you probably know that each exception in code is bad).

Also the problem with export script is, that we're exporting ONE form of all definitions for all formats (annotations, xml, yml) and than converting all based on some rules to final format.

And this is the problem. There is currently no way how to decide which of yaml (array vs child) form use. This means that we will have to implement some additional special flags to only some Gedmo extensions and this only because of Yaml which isn't widely used and which will be completely discarded with next Doctrine version (https://github.com/doctrine/doctrine2/pull/5932)

Also as I already pointed there are currently only two users who using Gedmo with Yaml. All other users are using annotation and XML definitions, because of benefits already covered by Marco Pivetta here - https://github.com/doctrine/doctrine2/pull/5932#issuecomment-233593524

As you can see it's a lot of work and additional increasing of complexity of export code for almost nothing.

As a solution for this problem I think it's the best to let Skipper to convert your project from Yaml to Xml/Annotations (it can be done with a few clicks by changing Module Export settings from Yaml to XML).

I understand that @Annotations don't fit to every developer but there is no difference between Yaml and Xml when both is stored in separate file and handled completely automatically by Skipper. Because of that I believe there is no reason why to prefer Yaml to XML when also core Doctrine2 developers recommend not to use Yaml anymore.

BTW, this is one of their statement:
@ocramius: annotations are good for in-house projects, please use XML for anything reusable/published.

---

Thanks for the additional information Ludek.

I wasn't aware that the YAML driver support was being dropped from Doctrine3, so that's very useful to know generally.

Given we're going to have to switch to XML anyway, we'll try it now where we have this issue and will let you know if we have any further issues.

---

Thanks for understanding. I believe XML is much stable format and we don't know about any export issue to Xml/Annotation. Feel free to let me know when you have any questions or issues with XML.