Callback for failure on document persist
opened this issue · comments
When documents are persisted, having the ability to specify a callback that is called on failure to persist a particular document would be immensely helpful.
This would allow developers to manage the conflicts automatically using code; or by providing users feedback of the conflict and letting them manage it.
I propose something like the following:
$documentManager->persist($document, function($error)
{
// Error management logic
});
If this were implemented as an optional parameter this would remain compatible with code using the existing api.
My question is: Were I to implement this feature and send a PR, would it be accepted?
Feature is good. But API should be an event that is fired on the event manager like onFlush/prePersist and such
Von meinem iPhone gesendet
Am 06.12.2011 um 19:46 schrieb Josiahreply@reply.github.com:
When documents are persisted, having the ability to specify a callback that is called on failure to persist a particular document would be immensely helpful.
This would allow developers to manage the conflicts automatically using code; or by providing users feedback of the conflict and letting them manage it.
I propose something like the following:
$documentManager->persist($document, function($error)
{
// Error management logic
});If this were implemented as an optional parameter this would remain compatible with code using the existing api.
My question is: Were I to implement this feature and send a PR, would it be accepted?
Reply to this email directly or view it on GitHub:
#37
Is there a reason why this should be an event rather than something that can be injected on persist?
If an even manager is used then distinguishing the event for a particular document (especially when there may not be an identifier) could be difficult.
Perhaps I could implement something that emits both a generic event and also allows you to define a callback specific to a document?
The context within which the failure occurred likely knows best how to deal with resolving the issue, not some generic callback.
Even if it can't be put on the persist call due to BC issues, it should somehow be injectable by the caller, rather than the subject or callee.