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

Id override is ignored if a property called 'Id' exists. #299

Open
alex-davidson opened this issue Jan 29, 2015 · 3 comments
Open

Id override is ignored if a property called 'Id' exists. #299

alex-davidson opened this issue Jan 29, 2015 · 3 comments

Comments

@alex-davidson
Copy link
Contributor

The following test fails:

[Test]
public void CanOverrideIdProperty()
{
    var model = AutoMap.Source(new StubTypeSource(new[] { typeof(EntityWithAlternateIdProperty) }))
        .Override<EntityWithAlternateIdProperty>(o =>
        {
            o.Id(e => e.AlternateId);
        });

    HibernateMapping hibernateMapping = model.BuildMappings().First();

    ClassMapping classMapping = hibernateMapping.Classes.First();
    ((IdMapping)classMapping.Id).Name.ShouldEqual("AlternateId");
}

public class EntityWithAlternateIdProperty
{
    public int Id { get; set; }
    public int AlternateId { get; set; }

    public string Name { get; set; }
}

It seems that AutoMapper#TryMapProperty considers only whether or not the property has already been seen, rather than considering the type of mappings being generated by the rule. The sequence of events seems to be something like:

  1. Override is applied, creating an IdMapping referring to AlternateId and applied at Layer.Defaults. AlternateId is marked as 'seen'.
  2. Begins applying defaults. Properties are iterated.
  3. The Id property is encountered. It has not yet been mapped, so the mapping steps are run against it.
  4. IdentityStep creates an IdMapping referring to Id and applies it at Layer.Defaults. This obliterates the IdMapping created by the override.

Adding o.Map(e => e.Id); to the override works around the problem because it prevents IdentityStep being executed for that property.

I would expect overrides to be applied at Layer.UserSupplied but this does not appear to be the case. Is this a bug, or intended behaviour?

@chester89
Copy link
Collaborator

Most likely it's a bug. Let me look into it. What version do you use?

@alex-davidson
Copy link
Contributor Author

I wrote the test against 30edae2, which was the tip of master at the time (29/01/2015?). We initially discovered the bug in the 1.3.0.734 version of the package.

Thanks!

@chester89
Copy link
Collaborator

I see, thanks

2015-03-04 14:32 GMT+03:00 Alex Davidson [email protected]:

I wrote the test against 30edae2
30edae2,
which was the tip of master at the time (29/01/2015?). We initially
discovered the bug in the 1.3.0.734 version of the package.

Thanks!


Reply to this email directly or view it on GitHub
#299 (comment)
.

С уважением,
Чермённов Глеб

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

No branches or pull requests

2 participants