Answered by:
EF 4 - POCO - Trimming properties for entities

Question
-
Hi,
We're using EF 4 with POCOs that are generated from the standard T4 template.
Our database uses fixed length nchars and so data is being returned with trailing spaces if the field doesnt use the full length, but we would like to remove these spaces as it's causing problems.
We're wondering what is the best way to do this??? The entities are automaticaly generated and we could alter the T4 template to trim the properties when set or returned but we havent experience modifying T4 templates so would prefer another method.
We could inherit from the generated class and Rtrim the properties which works fine for none key fields but for key fields EF gets confused as we have altered the key values and it thinks it's a different entity so it would be ideal to perform this trim earlier in the entity life cycle.... Is there another way?Friday, April 9, 2010 6:50 AM
Answers
-
Hi Stephen,
There is one more thing you have to consider when using fixed length strings as keys: whenever you save a new entity to the database, the key that you set is going to be padded on the server with spaces until it fills the fixed length. At this point the value of the key of the entity in memory and the value of the key in the database will no longer match.
That means that if you keep the ObjectContext instance around after you have saved changes, and you somehow query again for the same entity, the ObjectContext will not be able to identify that the entity coming from the database and the one that is in memory are the same.
The complete story is that if you are using fixed length strings as keys with Entity Framework, instead of trimming the keys when they come from the database, what you have to do is to pad the key value with the right length every time you create a new entity.
I suspect you should be able to solve this by simply padding on the property setter (i.e. using the String.PadRight method), because when the entity is being materialized from the database the key will already be of the right length, so padding will not introduce changes.
Alex James posted a detailed article explaining the issues in his blog last year:http://blogs.msdn.com/alexj/archive/2009/05/20/tip-20-how-to-deal-with-fixed-length-keys.aspx.
Thanks,
Diego
This posting is provided "AS IS" with no warranties, and confers no rights.- Marked as answer by Diego B Vega [MSFT]Moderator Friday, April 16, 2010 12:19 AM
Friday, April 16, 2010 12:19 AMModerator -
One approach I would suggest would be to create a "computed property" that returns the rtrim version of the string and in the setter just sets the appropriate property with the set value (it could optionally pad the mapped property, I suppose).
Your original suggestion of changing the value that is being set is not a good idea because then this value will always differ from the one that is stored in the POCO's snapshot (or if it was EOCO or a proxy, it would be registered as a change right away).
Jeff
This posting is provided "AS IS" with no warranties, and confers no rights.- Marked as answer by Jeff Derstadt - MSFTModerator Thursday, April 15, 2010 4:12 PM
Thursday, April 15, 2010 4:12 PMModerator
All replies
-
Altering the T4 template is straightforward and simple - inheriting from the generated classes is not a workable approach since LINQ queries against the database will not give you instances of these subtypes.
You could also use views and do the trimming on the server. If your model is read-only, that is a workable approach - and potentially more efficient than trimming on the client - especially if the client is going to write back the values to the server.
This posting is provided "AS IS" with no warranties, and confers no rights.- Proposed as answer by Jonathan Aneja -- MSFTModerator Tuesday, April 13, 2010 6:45 PM
Friday, April 9, 2010 5:52 PMModerator -
Altering the T4 template is straightforward and simple - inheriting from the generated classes is not a workable approach since LINQ queries against the database will not give you instances of these subtypes.
You could also use views and do the trimming on the server. If your model is read-only, that is a workable approach - and potentially more efficient than trimming on the client - especially if the client is going to write back the values to the server.
This posting is provided "AS IS" with no warranties, and confers no rights.Friday, April 9, 2010 5:52 PMModerator -
One approach I would suggest would be to create a "computed property" that returns the rtrim version of the string and in the setter just sets the appropriate property with the set value (it could optionally pad the mapped property, I suppose).
Your original suggestion of changing the value that is being set is not a good idea because then this value will always differ from the one that is stored in the POCO's snapshot (or if it was EOCO or a proxy, it would be registered as a change right away).
Jeff
This posting is provided "AS IS" with no warranties, and confers no rights.- Marked as answer by Jeff Derstadt - MSFTModerator Thursday, April 15, 2010 4:12 PM
Thursday, April 15, 2010 4:12 PMModerator -
Hi Stephen,
There is one more thing you have to consider when using fixed length strings as keys: whenever you save a new entity to the database, the key that you set is going to be padded on the server with spaces until it fills the fixed length. At this point the value of the key of the entity in memory and the value of the key in the database will no longer match.
That means that if you keep the ObjectContext instance around after you have saved changes, and you somehow query again for the same entity, the ObjectContext will not be able to identify that the entity coming from the database and the one that is in memory are the same.
The complete story is that if you are using fixed length strings as keys with Entity Framework, instead of trimming the keys when they come from the database, what you have to do is to pad the key value with the right length every time you create a new entity.
I suspect you should be able to solve this by simply padding on the property setter (i.e. using the String.PadRight method), because when the entity is being materialized from the database the key will already be of the right length, so padding will not introduce changes.
Alex James posted a detailed article explaining the issues in his blog last year:http://blogs.msdn.com/alexj/archive/2009/05/20/tip-20-how-to-deal-with-fixed-length-keys.aspx.
Thanks,
Diego
This posting is provided "AS IS" with no warranties, and confers no rights.- Marked as answer by Diego B Vega [MSFT]Moderator Friday, April 16, 2010 12:19 AM
Friday, April 16, 2010 12:19 AMModerator