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

Members with custom mapping definitions not populated unless $select is used #196

Open
jazzmanro opened this issue Nov 20, 2023 · 1 comment
Labels
enhancement New feature or request

Comments

@jazzmanro
Copy link

Starting from the samples in this repo, let's make OpsTenant.BuildingIds a List<int> and add a mapping:

Source/destination types

    public class OpsTenant : BaseOpsTenant
    {
        [Key]
        public Guid Identity { get; set; }
        public DateTime CreatedDate { get; set; }
        public List<int> BuildingIds { get; set; }
        public ICollection<CoreBuilding> Buildings { get; set; }
    }

Mapping configuration

            CreateMap<TMandator, OpsTenant>()
                .ForMember(d => d.BuildingIds, o => o.MapFrom(s => s.Buildings.Select(b => b.Id).ToList()))
                .ForAllMembers(o => o.ExplicitExpansion());

Version: 4.0.1

Expected behavior

BuildingIds should be populated when calling:
http://localhost:16324/opstenant

Actual behavior

BuildingIds is not populated by default unless I explicitly $select it:
http://localhost:16324/opstenant?$select=Identity,Name,CreatedDate,BuildingIds

I think this is an issue as it is not consistent with the other members behavior. BuildingIds is a simple member with a custom mapping, it is neither a navigation nor complex property, $expand won't work. To be forced to $select in order to access the data is not intuitive and also not practical as it requires to explicitly $select all other properties in order to get the default structure.

@BlaiseD
Copy link
Member

BlaiseD commented Nov 22, 2023

That's by design. With explicit expansion only the literal types will expand by default.

If you're interested consider the approach we use for including literal types and include a PR for the non-navigation/simple members.

@BlaiseD BlaiseD added the enhancement New feature or request label Nov 22, 2023
NetanelPersik pushed a commit to NetanelPersik/AutoMapper.Extensions.OData that referenced this issue Oct 18, 2024
NetanelPersik pushed a commit to NetanelPersik/AutoMapper.Extensions.OData that referenced this issue Oct 20, 2024
NetanelPersik pushed a commit to NetanelPersik/AutoMapper.Extensions.OData that referenced this issue Oct 21, 2024
NetanelPersik pushed a commit to NetanelPersik/LogicBuilder.DataComponents that referenced this issue Oct 27, 2024
NetanelPersik pushed a commit to NetanelPersik/LogicBuilder.DataComponents that referenced this issue Oct 27, 2024
BlaiseD added a commit to BpsLogicBuilder/LogicBuilder.DataComponents that referenced this issue Nov 2, 2024
…on/simple members. (#52)

* feat(primitive-collections): including literal types for non-navigation/simple members.

AutoMapper/AutoMapper.Extensions.OData#196

* Minor: separation of concerns.

---------

Co-authored-by: netanelpersik <[email protected]>
Co-authored-by: Blaise Taylor <[email protected]>
NetanelPersik pushed a commit to NetanelPersik/LogicBuilder.DataComponents that referenced this issue Nov 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants