Use a Dictionary type as a User Defined Type

Hi Guys,

I wanted to serialise some object to a string field in the DB, and thought I could use IFieldConverter. However, I am getting an error...

Additional information: Unsupported field type 'System.Collections.Generic.Dictionary`2[System.String,System.String]' for non-transient field NahModel.Db.ExtraInput._options

I am using the following code, although this doesn;t seem to be getting hit...

    public class DictionaryStringPairType
    {
        internal class DictionaryStringPairTypeConverter : IFieldConverter
        {
            public object ConvertFromDatabase(object databaseValue)
            {
                if (databaseValue == null) return null;
                return ((string)databaseValue).FromJsv<Dictionary<string, string>>();
            }

            public object ConvertToDatabase(object value)
            {
                if (value == null) return null;
                return value.ToJsv();
            }
        }
    }

And the following User Defined Type

• CLR Type Name : System.Collections.Generic.Dictionary
• Converter Type : Convertor.DictionaryStringPairType.DictionaryStringPairTypeConverter
• Data Type : String
• Is Standard Data Type : True
• Is Value Type : False

• Name : DictionaryStringPairType

  Should I be able to do what I am trying to do?

Cheers, Sean

No, you have specified a non generic type as the CLR name but the actual type has generic parameters. Ill have a look at making a tweak to support this so it accepts anything which would match the base signature on the assumption its a generic type and you will know what you are doing.

Ill post an update once Ive had a chance to progress this further, so hopefully will have something for the nightlies later this week.

Jeremy

Awesome - thanks Jeremy.

Ive merged the changes for this today so this will be available in the next nightly build. For your UDT specify Dictionary as the CLR type as this will be used for code-gen and will need to match up to your field converter. The exception you are seeing has been removed which will allow the calls to the converter to be progressed and everything should work happily from there.

Let us know if you run into any other issues after updating.

Jeremy

Thanks for this Jeremy, it's great!!

There is just one thing to be aware of, I'm not sure anything can really be done about it either, although you may have some suggestions : )

If it is say a Dictionary type, and you change the content by editing or adding to it directly or by reference the entity is not marked as modified. Now I understand that LS wouldn't change the entity state in this instance as there is no trigger in the dictionary to let it know.

Is there some way to force a changed state on the entity here, or should we manually make a change to a field to create the changed state?

Cheers, Sean

Yep - any manipulation of a properties object state without causing re-assignment is not going to trigger an indication to the entity that the state has changed, similarly on assignment we do an equality check to determine if the object is new or is just the same value being re-assigned before making the property as dirty (which in turn changes the EntityState) so in the case of a Dictionary you would be still dealing with the same object if you re-assigned it.

A couple of ways I can think of that you can handle this would be:

• Dont use the UDT for the field type, have a seperate property which exposes the dictionary and serializes out to an underlying string storage value on change - this requires you to detect change in the Dictionary. The change in the storage value would trigger a change in the EntityState
• Sub-class the Dictionary so you can override the Equals() method and allow equality to be based on the state of the Dictionary then have a wrapper method on your Entity for updating the Dictionary which calls "Set" re-assigning the value of the Dictionary field back to itself - the equality check would indicate there is a change which in turn would modify the EntityState

There isnt really an elegant way of handling this, and Dictionary doesnt seem to expose any change events so I would be thinking the second approach might be the best here. YMMV :)

Jeremy