YML export - Gedmo soft_deleteable has broken following a recent Skipper upgrade (3.2.10.1370)

Question

Hi.

Other people have recently raised the issue of YML export being incorrect when it comes to outputting Gedmo behaviours. I am having a similar problem with SoftDeletable.

Before a recent upgrade to 3.2.10.1370, the YML was being generated correctly:

gedmo:
  soft_deleteable:
    field_name: deleted_at

But it's now exporting as

gedmo:
  - soft_deleteable:
      field_name: deleted_at

This has broken my entire project.

I tried to follow advice to go for XML export, but when I try that a number of my entities report "No identifier/primary key specified for Entity" when I'm using a primary key not called 'id'.

What's my best solution?

Thanks
Dave

Answer 1

Hi Dave,

as mentioned in previous answers, there are serious problems with YAML Gedmo definitions. There are two (maybe three) kind of formats which Gedmo YML is using. And when we fixed the first one, we broke the second one.

The first one is using referred "- anything" format and the second one "anything" format.

And unfortunately, it isn't possible to maintain such inconsistent form. So yes, you're right that versions before 3.2.10 exported correctly mentioned situation (soft* vs -soft*) but incorrectly exported another half of use cases. And when we fixed the second half, we broke the first one.

Because of such inconsistency together with official statements that Yml will not be supported in future Doctrine versions (for example here) we decided to surrender our attempts and left yml format in current state.

The best way what can our users do is to re-export all definitions to the different format. Because you (and a lot of other users) are using Skipper to export Doctrine2 definitions, there is no reason to export it to inconsistent YML instead of fully supported and explicit XML.

It's a matter of few clicks to change the format from YML to XML. After that, you will get fully functional export and complete Gedmo support.

Although we loved to support all formats (including the forbidden ones) we're not able to support such inconsistent format which using several forms to describe the same thing.

Thanks for understanding.

Comments

Thanks for the feedback Ludek... I understand the reasons, but it does leave us in a difficult position which we didn't expect to be in at the end of a busy week.

As I said in my first post, when using the XML export we have some entities which use as their primary key a foreign key from another entity and we're seeing "No identifier/primary key specified for Entity" when trying to generate entities from the XML.

Let's say that my NewsItem has properties id and name. There's another entity NewsItemExtra, which has a one-to-mapiing with NewsItem (it holds a lot of extra data)

Currently NewsItem has id (INT, primary key, autoincrement) and name (STRING) and NewsItemExtra has newsitemid (INT, primary key, foreign key, not autoincrement) and lots of of properties (not relevant to this example).

Under this scenario, we're seeing "No identifier/primary key specified for Entity 'NewsItemExtra'" when trying to generate entities from XML, but it works fine with the exported YML.

We inherited this system, so understand that it might not be the best model to use, but why should it work with YML and not XML?

Dave

---

David,
I didn't notice a note about the error with XML format. But this is completely strange because we didn't receive any similar error report yet.

Although I understand that from your point of view would be simpler to use YML, in long term view you will have to solve XML issues anyway. It's a matter of time when YML format will be abandoned.

Although it's currently more work for you, the best would be to backup your Skipper project file and remove all entities one-by-one until you will find what what causing this weird error.

In case that this issue is caused by Skipper by some invalid export format, we can fix it withing few hours as soon as you will send us what exactly is exported wrongly. Also in the case that this is caused by some bug in Doctrine2 I believe they will be willing to provide the fix asap.

Unfortunately, in the case of YML format of Gedmo extension, there is no way how to get any update/bugfix. Some time ago we tried to cooperate and maintain Gedmo extensions but the current state of the plugin isn't a ready for any easy fixes/extensions and original author doesn't have a free time to make any larger changes.

Thanks for understanding
Ludek

---

Hi Ludek.

Thanks for engaging with this issue. I have stripped back our model until it contains only two entities, and the problem remains.

Here's our model:

The generated XML follows:

<?xml version="1.0"?>
<doctrine-mapping xmlns="http://doctrine-project.org/schemas/orm/doctrine-mapping" xsi="http://www.w3.org/2001/XMLSchema-instance" schemaLocation="http://doctrine-project.org/schemas/orm/doctrine-mapping.xsd">
  <entity name="Client\NewsBundle\Entity\NewsItem">
    <id name="id" type="integer">
      <generator strategy="AUTO"/>
    </id>
    <field name="name" type="string" length="200" nullable="false"/>
    <one-to-one field="NewsItemExtra" target-entity="Client\NewsBundle\Entity\NewsItemExtra" mapped-by="NewsItem"/>
  </entity>
</doctrine-mapping>

and

<?xml version="1.0"?>
<doctrine-mapping xmlns="http://doctrine-project.org/schemas/orm/doctrine-mapping" xsi="http://www.w3.org/2001/XMLSchema-instance" schemaLocation="http://doctrine-project.org/schemas/orm/doctrine-mapping.xsd">
  <entity name="Client\NewsBundle\Entity\NewsItemExtra">
    <id name="news_item_id" type="integer" association-key="true"/>
    <field name="extra_data" type="string" length="200" nullable="false"/>
    <one-to-one field="NewsItem" target-entity="Client\NewsBundle\Entity\NewsItem" inversed-by="NewsItemExtra">
      <join-columns>
        <join-column name="news_item_id" referenced-column-name="id" nullable="false" unique="true"/>
      </join-columns>
    </one-to-one>
  </entity>
</doctrine-mapping>

When I try to generate the entities I get this error:

  [Doctrine\ORM\Mapping\MappingException]                                                                               
  No identifier/primary key specified for Entity "Client\NewsBundle\Entity\NewsItemExtra". Every Entity must have an i  
  dentifier/primary key.  

Now, I've taken a look at http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/tutorials/composite-primary-keys.html (the Identity through foreign Entities section) and it says:

The semantics of mapping identity through foreign entities are easy:
Only allowed on Many-To-One or One-To-One associations. Plug an @Id
annotation onto every association. Set an attribute association-key
with the field name of the association in XML. Set a key
associationKey: with the field name of the association in YAML.

In the NewsItemExtra XML if I manually change

<id name="news_item_id" type="integer" association-key="true"/>

to

<id name="NewsItem" type="integer" association-key="true"/>

the entities are generated correctly and things seem to be working again.

Is this a lack of my understanding, or a problem with the generated XML, do you think?

Thanks
Dave

---

Hi Dave,

thanks for the detailed information. Based on what you have found it seems to me like a bug in Skipper.

What is strange that we have a very similar test case in our repository where we have also "columnnameid" and I believe it is copied from Doctrine tests or documentation.

So maybe some time ago this was also allowed format but the latest version of Doctrine needs to have "FieldName" instead.

Anyway, we will update exporters to export field name instead of column name. I believe this will be a quick fix. Give me some time to prepare update, tests and release it.

I will let you know.

---

It's strange. In case that needs to be filled with association alias (NewsItem) instead of column name (newsitemid), how can be implemented multi-column relation?

---

It's fixed now, please let me know if it works for you too.

https://support.skipper18.com/402/downloads-skipper-beta

Regarding my last comment, it's possible to create it also for multi-column relations, because each association can hold multiple columns

---

HI Ludek. Thanks for this. I'm on annual leave in a few days' time so will have to leave this until I return at the start of June - for the moment I've rolled back to a previous version so that my team can continue its work. Thanks for looking into it and for the new beta... I'll let you know ASAP. Dave

---

Sure, you're welcome. Enjoy your vacation.