Refactor internal transformer methods to be more strict #256

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
3 participants
@jmikola
Member

jmikola commented Mar 27, 2013

Be strict about incoming values to transformNested(). 82ec81c introduced support a non-iterable $objects parameter, and proxied to transform(). This method should never be called in that case, so throwing an exception should allow us to catch bad logic or mappings.

Additionally, do not accept ArrayAccess objects when we expect an iterable value. Support for ArrayAccess in normalizeValue() dates back to 0db0490 (likely an oversight).

Lastly, use an equality check instead of calling is_null(), as it is more efficient.

Refactor internal transformer methods to be more strict
Be strict about incoming values to transformNested(). 82ec81c introduced support a non-iterable $objects parameter, and proxied to transform(). This method should never be called in that case, so throwing an exception should allow us to catch bad logic or mappings.

Additionally, do not accept ArrayAccess objects when we expect an iterable value. Support for ArrayAccess in normalizeValue() dates back to 0db0490 (likely an oversight).

Lastly, use an equality check instead of calling is_null(), as it is more efficient.
@jmikola

This comment has been minimized.

Show comment Hide comment
@jmikola

jmikola Mar 27, 2013

Member

@daFish: Since this reverts some purposeful changes you made in #216, feel free to chime in.

Member

jmikola commented Mar 27, 2013

@daFish: Since this reverts some purposeful changes you made in #216, feel free to chime in.

@jmikola

This comment has been minimized.

Show comment Hide comment
@jmikola

jmikola Mar 28, 2013

Member

See follow-up comments in #216 (comment)

Member

jmikola commented Mar 28, 2013

See follow-up comments in #216 (comment)

@daFish

This comment has been minimized.

Show comment Hide comment
@daFish

daFish Mar 28, 2013

Contributor

@jmikola Unfortunately I'm out of ideas here right now for a better solution but as long as we'd still be able to index nested objects, even if they're null, then I'm fine with every solution.

Contributor

daFish commented Mar 28, 2013

@jmikola Unfortunately I'm out of ideas here right now for a better solution but as long as we'd still be able to index nested objects, even if they're null, then I'm fine with every solution.

@jmikola

This comment has been minimized.

Show comment Hide comment
@jmikola

jmikola Mar 28, 2013

Member

@daFish: Based on the ES documentation for object and nested types, it looks like these are comparable to @Embed and @EmbedMany in Doctrine ODM, respectively. In that case, I think it's be more clear to handle them separately.

Fields mapped as object should be transformed, but no iteration should take place. Those mapped as nested should be iterated over, with each element being transformed. I suppose each should have an allowance for null, which should be transformed to the empty representation of both. But in terms of indexing, if a field is null, shouldn't it be omitted from the stored ES document altogether?

Member

jmikola commented Mar 28, 2013

@daFish: Based on the ES documentation for object and nested types, it looks like these are comparable to @Embed and @EmbedMany in Doctrine ODM, respectively. In that case, I think it's be more clear to handle them separately.

Fields mapped as object should be transformed, but no iteration should take place. Those mapped as nested should be iterated over, with each element being transformed. I suppose each should have an allowance for null, which should be transformed to the empty representation of both. But in terms of indexing, if a field is null, shouldn't it be omitted from the stored ES document altogether?

@daFish

This comment has been minimized.

Show comment Hide comment
@daFish

daFish Mar 29, 2013

Contributor

@jmikola I see. Yeah, I wondered before why object was treated the same way than nested. I see if I can come up with a solution based on your suggestion. Thanks, Jeremy.

Contributor

daFish commented Mar 29, 2013

@jmikola I see. Yeah, I wondered before why object was treated the same way than nested. I see if I can come up with a solution based on your suggestion. Thanks, Jeremy.

@merk

This comment has been minimized.

Show comment Hide comment
@merk

merk Jul 23, 2014

Member

This PR is too stale to be merged, and transformers are scheduled to be refactored into a new approach in 3.2

Member

merk commented Jul 23, 2014

This PR is too stale to be merged, and transformers are scheduled to be refactored into a new approach in 3.2

@merk merk closed this Jul 23, 2014

@merk merk deleted the transform-refactoring branch Jul 23, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment