We have a feature to implement: We need multiple groups for customers. And because we already have good experience with tags, we implement it with tags. Customer is part of a band? Cool, give them the tag “Die Prinzen“. They are part of multiple bands? No problem, tag them with “Versengold” also.
Do I just made up an example to give a shout out to great bands? Yes.
When was the tag added?
Now the customer came around with another feature: We want to “log” when the tag was added. Easy! We just extend the customer_tag table, add a created at and done. Thomas got the ticket and came back to me to discuss the issue. My idea to “just” add a created at and done had a few … flaws.
But what about the entity?
At first glance this sounds like a great idea, but on the second we realised this works only for entities. And the customer tag has a CustomerTagDefinition but not entity. Which totally makes sense, because it is only a join table to connect tags and customer.
Even if we would like to, what is the expected outcome? We have a customer with a tag collection – and where to we expect the created_at from our table?
Just overwrite the created_at on the tag
One idea was to overwrite the created_at on the tag. So we have a customer entity with a tag collection and can read on the tag, when the connection was made. This means we change the meaning of the created_at on the tag. One could make this, but it is unintuitive and that means it will cause trouble in the future.
So if you do that, be prepared!
Create a new entity
One other idea is, to create a new entity to kind of “replace” the tag, to add more infos to the connection, but that means we potentially changing a lot of code.
Create a new attribute
What about creating a new attribute on the tag? connectionCreatedAt or whatever to call it? This was out best idea we came up with.
Add column to customer_tag
We add a migration to add a column to customer_tag, so we can save the created_at.
Hack the DBAL
Because the DBAL doesn’t know the new column, we need to hack it, so late, that all the validations and checks based on the criteria are done, but so early, we don’t have SQL already. We are sure, there is an event for that in doctrine, but didn’t dig deeper – if you do, leave a comment and tell us about!
Last but not least: The hydrator
Thomas looked into the hydrator, but my point of view is: After getting the data from the database, we need to make sure to write this new, unknown, weird column during hydration into the TagEntitys new property connectionCreatedAt.
TL;DR No.
In short: We decided against it, because our PM Jan reminded us, that in essence we don’t necessarily need to save the created_at of the customer_tag but we need a log when it was added.
And this is the moment, we are reminded, that it is always good to not only talk with developers, but sometimes have someone else on the team, be it a designer, product owner or project manager.
Our solution: EntityExtension!
And so the circle closes. But we don’t do an entity extension on the tag or customer_tag but on the customer. So we just save a row to the database, when a tag is added.
One thought on “Shopware 6: How to NOT extend … non-entities”