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

FetchXml query returns expando with invalid property names #76

Open
BrettBailey opened this issue Dec 10, 2018 · 6 comments
Open

FetchXml query returns expando with invalid property names #76

BrettBailey opened this issue Dec 10, 2018 · 6 comments

Comments

@BrettBailey
Copy link

BrettBailey commented Dec 10, 2018

If you build a fetch xml query with joins each entity is aliased eg

<link-entity name=""contact"" from=""contactid"" to=""cn_contactid"" link-type=""inner"" alias=""alias"">

this produces properties in the expando such as alias.fullname, alias.email1 etc which are not valid .net property names.

it should create an alias property which is also an expandoobject and add the properties to the alias collection.

This can be worked around by casting the expando to a dictionary but if you have to do that each time you may as well not bother making the expando in the first place.

image

@davidyack
Copy link
Owner

Agree this is painful the way OData works - similar occurs with Formatted values - Are you suggesting aliasfullname or adding an object alias with property of fullname. Either way we would have to process the object which is messy...Open for ideas here

@BrettBailey
Copy link
Author

I think the best approach would be to create an object for the alias with properties for its fields such as firstname. This would produce a useable expando and protect from name clashes etc.

Alternatively, you could use a naming convention. for example instead of calling the property alias.fullname call it alias_fullname - that should be a simple text substitution and would result in a useable object but would clash with any existing alias_fullname fields.

Another approach would be to not convert the result to an expando at all - just return a dictionary.

@simba22042
Copy link

Hi Guys,

How was this resolved?

I have the following

var api = await GetAPI();

            CRMGetListOptions buOptions = new CRMGetListOptions()
            {
                FetchXml = @"<fetch no-lock='true'><entity name='account'><attribute name='accountid'/><attribute name='name'/><attribute name='accountnumber'/><filter type='and'><condition attribute='accountnumber' operator='not-null'/></filter><link-entity name='contact' from='contactid' to='primarycontactid' link-type='inner' alias='contact'><attribute name='fullname'/></link-entity></entity></fetch>"
            };
            var accounts = await api.GetList("accounts", buOptions);
            foreach(dynamic account in accounts.List)
            {
                Console.WriteLine(account.accountid + " " +   account.name  + " " +  account.accountnumber);
                Console.WriteLine(account.contact.fullname);
            }

But getting the following

'System.Dynamic.ExpandoObject' does not contain a definition for 'contact'

@davidyack
Copy link
Owner

That is not account.contact it's account["contact.fullname"] the property is the alias plus the field
So you could do something like

    var myAccount = account as IDictionary<string, object>;
        
      Console.WriteLine(myAccount["contact.fullname"]);

@simba22042
Copy link

I was getting Cannot apply indexing with [] to an expression of type 'System.Dynamic.ExpandoObject' with Console.WriteLine(myAccount["contact.fullname"]); so had to cast the reference to the interface to access it:

Like
((IDictionary<String, Object>)account)["contact.fullname"];

@davidyack
Copy link
Owner

Correct you can't do it on the expando directly that is why I had

var myAccount = account as IDictionary<string, object>;

Then you don't need to cast each line

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

No branches or pull requests

3 participants