Why must I use an int when searching for an entity with an OptionSetValue attribute, but use an OptionSetValue object when creating an entity?

Question

I'm seeing an inconstancy with how the CRM SDK treats searching for entities by an OptionSetValue attribute, and creating an entity with an OptionSetValue Attribute.

Back Ground:

I have a method with this signature

GetOrCreateEntity<T>(IOrganizationService service, params object[] columnNameAndValuePairs)

where the columnNameAndValuePairs is a list of pairs that look like this: (string name of the column, value of the column) ie. "name","John Doe" goes to entity.name = "John Doe".

It could be used like this:

var user = GetOrCreateEntity<SystemUser>("username", "jdoe");

Which would create and execute a query expression for a SystemUser entity with the username jdoe. If it isn't found, it would create one, populating the username attribute with "jdoe", and then creating the object.

Problem:

This works great in most instances, unless I'm searching/creating an OptionSetValue attribute. So say something like this:

var user = GetOrCreateEntity<SystemUser>("username", "jdoe", "Sex", new OptionSetValue(1));
var user = GetOrCreateEntity<SystemUser>("username", "jdoe", "Sex", 1);

If I pass in OptionSetValue(1) the query expression search fails, but if I pass in 1 the query expression executes without error, but the service.Create(entity) fails because it expects an OptionSetValue.

It would be easy for me to check for an OptionSetValue value, and send the int value into the QueryExpression, but am I just want to make sure I'm not doing something wrong. Did Microsoft really expect you to create the entity populating the attribute as an OptionSetValue but searching for it as an int?

Answer 1

I can't speak for Microsoft, but this sounds/looks right. It might be important to note that you search with FetchXml or a QueryExpression which have different schemas from a DynamicEntity (CRM 4) or just Entity (in CRM 2011) which are used for creating/updating.

Even in CRM 4 where CRM had wappers for common types (CrmBoolean, CrmNumber) you had to query by the CLR type but create/update with the wrappers. Also note that EntityReference are the same scenario. You search by the Guid, but must create/update with the EntityReference.