Skip to content
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

Evaluate IMemberConfigurationExpression conditions before resolve value #446

Closed
ChristianBirkl opened this issue Jan 15, 2014 · 2 comments
Closed
Labels
Milestone

Comments

@ChristianBirkl
Copy link

Hi,

it would be nice if conditions are evaluated before ResolveValue is called in order to avoid executing code (i.e. calling the getter of the underlying property) which won't be needed anyway because a condition will return false.

Specifing IMemberConfigurationExpression.Ignore() would work since this is evaluated before resolving the value but my use case depends on dynamic variables.

Source:

TypeMapObjectMapperRegistry::PropertyMapMappingStrategy:MapPropertyValue()

All conditions are evaluated in line 133, but the source value is resolved in line 104.

try
{
   result = propertyMap.ResolveValue(context);
}

// snip...

if (!propertyMap.ShouldAssignValue(newContext))
                        return;

Use Case where this is helpful:

If you have an application with EntityFramework and have implemented a property based security layer which may or may not map a certain property based on privileges you can use the op.Condition () method to define these rules. But currently AutoMapper invokes the getter and therefore triggers an SELECT which may not be needed since the condition returns false anyway.

@jbogard
Copy link
Member

jbogard commented Apr 10, 2014

What I wound up doing is creating overloads for PreConditions. Instead of Condition, use PreCondition. There were a lot of folks that wanted the current conditions where they are (as shown by the failing tests I got), so this way you can use preconditions when you don't want the source/destination value resolved before checking the condition.

@lock
Copy link

lock bot commented May 8, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked as resolved and limited conversation to collaborators May 8, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants