This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Hi I'm using LS 4.0, and have taken a look at this thread which suggests using a custom FieldConverter for nullable enum properties which are represented as strings in the database. So I derived a new class from FieldConverter:
The TEnum type parameter is expected to be a nullable enum (if it were constrained to a struct/enum type, ConvertToDatabase wouldn't be able to handle nulls). That means I need to set up the Converter Type property of the user defined type to NullableStringEnumFieldConverter This works fine for reading/writing data. But it doesn't work if I want to query for entities based on a value of the enum. In that case the ConvertToDatabase method is never called, and a LightSpeedException "This type of expression is not supported in a predicate" is thrown. That seems to happen because of the way I've declared the Converter Type property (taking a nullable enum as a type parameter). If I change it back to NullableStringEnumFieldConverter So, I have a few questions: 1) Could I have come up with a more suitable type for my FieldConverter implementation? I've played around with:
2) Is there a good reason why LightSpeed can't deal with nullable fields independently of the converter implementations (and of the user defined type)? My expectation was that LS would be able to handle nulls and DBNulls based on the nullability of the entity properties, and only use the converter for non-null values. 3) Has anything changed in LightSpeed 5 which might make this easier? |
|
|
The field converters are a hook to allow you to convert data in/out between the database and the model, so we pass the data in expecting that the converter implementation will handle DBNull etc. Its raw that way but gives you more control over the behaviour. In terms of your converter, that exception gets raised if there is a cast exception which may be being raised from the converter, or it may be being raised when we call the converter - you mentioned that with the generic implementation the ConvertToDatabase was not being called at all in this case - if so I can have a look to see where this might be being raised from and see if there is an issue we can resolve here. There have not been any changes in LightSpeed 5 around this, so you would expect the current behaviour in 5.0.
|
|
|
Hi Jeremy, Thank you for looking into this. My setup is as follows:
And that's right, ConvertToDatabase is not being called if I try to query on the enum property value (for example Saying that, I'm not convinced I'm approaching this in the best way. I had originally envisaged writing a converter implementation that'd work whether or not the Entity Property was nullable. But I gave up, and the way I'm doing it now, if anyone changes the nullability of an Entity Property, they have to remember to go and change the Type (or the type converter used by the user-defined type) too. Would it be possible to write an FieldConverter implementation that'd work (and be used) regardless of the nullability of the enum-valued Entity Property? My understanding was that it's not, because the CLR type will be different in each case (MyEnum vs. Nullable
and doing all the .NET type checking at runtime against typeof(TEnum) in the convert methods. Would that be the more sensible approach? |
|
|
Yes, the CLR type will be different in each case so you would need a separate converter, otherwise it will blow up (probably exactly as it was previously). Im not entirely sure if the FieldConvertor Let us know how you get on and if you encounter any issues with this!
|
|
|
Hi Jeremy, The FieldConverter approach does indeed work, once I finally figured out what the type of the converter needed to be. This should work whether or not the Entity Property using the User Defined Type is set to be nullable (without needing separate converters):
Thank you for helping me think this through! |
|