Feature request: publicly expose AttrAttribute.PropertyInfo getter

[bart-degreed]

Description

The resource graph builder performs traversal of relations to resolve the matching PropertyInfo instance for filters like ?filter[user.id]=1. It follows the resource.User property and points to its .Id property. I need access to that property in order to implement deep searching using Elasticsearch. Aside from the duplication, it does not seem easy/possible to re-implement that myself.

Furthermore, once this is exposed, it looks like InternalAttributeName can be removed. Which is a good thing, according to this documentation:

        /// <summary>
        /// Do not use this overload in your applications.
        /// Provides a method for instantiating instances of `AttrAttribute` and specifying
        /// the internal property name.
        /// The primary intent for this was to enable certain types of unit tests to be possible.
        /// This overload will be deprecated and removed in future releases and an alternative
        /// for unit tests will be provided.
        /// </summary>
        public AttrAttribute(string publicName, string internalName, bool isImmutable = false)
        {
            PublicAttributeName = publicName;
            InternalAttributeName = internalName;
            IsImmutable = isImmutable;
        }

Existing unit tests can then use .PropertyInfo.Name instead.

Please let me know if there are any objections to this. I'd be happy to submit a PR once approved.

Environment

latest master branch

[bart-degreed]

Another use case is that I'd like to be able to put custom System.Attributes on resource properties. Having access to PropertyInfo makes it easy to read them.

[bart-degreed]

@maurei @wisepotato @jaredcnance

Can anyone with merge permissions on JADNC approve for me to start working on this?

[maurei]

Apologies for the late reply: I've been ill past 8 days and in general low on development resources.

I see no objections. I think in the future we should move away from storing all this metadata in AttrAttribute but have a centralized meta object (like EF cores metadata) to store all such information. That would allow us to build a separate, probably fluent API for configuring models without having to write code in the models itself (this might not always be possible eg when models are in a 3rd party assembly).

But that's not an objection for now. I would be happy to review your work on this once you get there!

Cheers

[bart-degreed]

I hope you're feeling better by now. I've created #662 for this.