Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve and simplify integration with ORM internals #28

Merged
merged 3 commits into from
Jan 8, 2024
Merged

Conversation

mpdude
Copy link
Member

@mpdude mpdude commented Jan 8, 2024

This PR contains the following improvements:

  • It rewrites parts of how the PolyglotListener injects Translatable into entities when they are loaded and/or updates are flushed to the database. IMHO it's less interference with ORM lifecycle methods. We can avoid keeping a list of all entities with translations in PolyglotListener, which helps with garbage collection.
  • Previously, it was not possible to use translations with entities from an inheritance hierarchy. Now, every class in the hierarchy can define its own @TranslationsCollection and its own translations class. The translations class should only contain fields present in the corresponding class in the inheritance tree. The @Locale annotation will be searched for on parent classes as well.

@mpdude mpdude merged commit fe96e07 into 3.x Jan 8, 2024
6 checks passed
@mpdude mpdude deleted the improve-clean branch January 8, 2024 17:18
mpdude added a commit that referenced this pull request Jan 9, 2024
…. objects (#30)

To avoid side effects during Doctrine ORM PHP-value-to-database-value
conversion, this PR in part reverts design changes from #28:

On the `preFlush` event, remove all `PersistentTranslatable` instances
from managed entities and replace them with their plain (primary)
values. On `postFlush`, but the `PersistentTranslatable`s back in place.

That way, the default (plain) values are in place when the ORM does its
change detection.

Previously, in fact `PersistentTranslatables` were casted to string when
the ORM gathered the values to insert into the database. That does not
work when the column type is `object`, since it would try to serialize
the `PersistentTranslatable` itself.
This was referenced Mar 22, 2024
mpdude added a commit that referenced this pull request Apr 25, 2024
It may be useful to use the `#[Polyglot\Translatable]` attribute (or the
corresponding annotation) on properties that are not configured as
mapped Doctrine ORM fields. For example, the property value might be set
by entity lifecycle callbacks or Doctrine listeners.

It was possible to do so until #28 changed
`\Webfactory\Bundle\PolyglotBundle\Doctrine\TranslatableClassMetadata::findTranslatedProperties`
to work based on Doctrine ORM `ClassMetadata` information and fields.
This was done to simplify detection of whether a particular property
belongs to a given class or needs to be mapped through base class
translations. Obviously, `ClassMetadata` does not know about unmapped
properties.

This PR changes the code to work on PHP reflection data instead,
restoring functionality.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant