You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Because we cannot modify the filters defined in ClassMethods for instance, the only way we have to filter properties is to use unset. Not really a problem, with one exception. Imagine you have an entity:
Of course, we could use the hydrator to unset the "active_members_count" property if we don't want it, BUT it generated a useless SQL query that is indeed not needed by the extraction method of the hydrator.
What I suggest is allowing to pass a specific filter to ClassMethods constructor, so it leaves the chance to add filters (like ExcludeMethods one) that get appended to the filter chain. We still have the performance benefits as this can be set only in the constructor.
The text was updated successfully, but these errors were encountered:
After using this prototype's philosophy and never extending ClassMethods but rather composing it, I feel that this is actually a nice idea. However there is one caveat: https://github.com/zf-fr/hydrator#why-built-in-hydrators-are-final-and-how-should-i-use-them
Because we cannot modify the filters defined in ClassMethods for instance, the only way we have to filter properties is to use unset. Not really a problem, with one exception. Imagine you have an entity:
Of course, we could use the hydrator to unset the "active_members_count" property if we don't want it, BUT it generated a useless SQL query that is indeed not needed by the extraction method of the hydrator.
What I suggest is allowing to pass a specific filter to ClassMethods constructor, so it leaves the chance to add filters (like ExcludeMethods one) that get appended to the filter chain. We still have the performance benefits as this can be set only in the constructor.
The text was updated successfully, but these errors were encountered: