Closed sydekumf closed 10 years ago
Yes the preflush and postflush event arguments only contain the SearchManager as that follows the Doctrine ORM pattern. It may be possible to return the identity map as you suggest but it might take a bit of work since the map is actually split into entities for persistence and entities for removal. It may require some thought about how to organise the map.
Alternatively, you can use prePersist, preRemove, postPersist, and postRemove listeners with no problem. This can be useful because you can cascade persist or remove related entities before the flush bulk operation executes.
Sure, I can use prePersist
, you're right thanks.
But what do you mean, it requires some thought? What about two simple get functions in the unit of work class for scheduledForPersist
and scheduledForDelete
?
Well what i meant was that we should try to unify the maps, and also there is the issue of ElasticSearch generated ids which might affect the map structure in future. Maybe simple getters is a quick fix but i guess if you can work with prePersist/postPersist then we can focus on the other issues first.
Closing this in lieu of #89
If you write an event subscriber for the
preFlush
event, you only get theSearchManager
as argument. Unfortunately the search manager isn't capable of returning the entities which will get flushed. I need them to interact with them before flushing them. Can this be implemented somehow or isn't it supposed to be that way? How do you get your entities in an event subscriber in general?Edit: Just looked up the source of doctrine. You can get the unit of work by the search manager. And the doctrine unit of work has a function for returning entities, but not the doctrine/search unit of work: http://www.doctrine-project.org/api/orm/2.4/source-class-Doctrine.ORM.UnitOfWork.html#_getIdentityMap Would it be possible to implement that or can I do a pull request?