-
-
Notifications
You must be signed in to change notification settings - Fork 903
Conflict between original_data
cloning and application cloning in WriteListener
#6362
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
Comments
This is definitely a problem for us. My API uses entities from a shared library, and several entities have __clone functions that intentionally do not copy over the id. Things would be ok if the IRI wasn't generated based on previous data, but on current data. |
OK. I have a work around for those of us who stubbornly wanted to update. You can decorate the WriteListener Here is my quick implementation. (I've just banged it out and not put it through any significant tests yet)
|
Thanks for the detailed report I'll fix this, indeed it looks like cloning is not needed there, can you confirm the patch solves your issue? Thanks. |
@soyuka Works, thank you. |
API Platform version(s) affected: 3.3.2
Description
I noticed that in PR #6102 was added feature to clone
original data
in Symfony WriteListener. Thisorignal data
are further used to generate Content-Location header.However when someone already use __clone() on Entity (original data object) to provide some other bussiness functionality and resets
id
property (for example):Generating Content Location header fails with Metadata RuntimeException
No identifier value found, did you forget to persist the entity?
How to reproduce
Simple
GET /api/entity/{id}
with __clone() method setting ID property to null results to RuntimeExceptionOf course, this issue applies only for Symfony (
use_symfony_listeners: true
)Possible Solution
I'm not sure why is cloning
original data
even needed.The text was updated successfully, but these errors were encountered: