UDT Problem
Joined: 06-May-2008
Joined: 06-May-2008
Hi,
[quotenick="Walaa"]This should work without any manual intervention.
Ok..we got the type converter running now (thanks to reflektor CreateInstance is important 
The UDT is registered in GAC and SQL-Server.
The problem with the above stack trace (null reference excepotion) still present..
any idea? The UDT is serialized into xml..the xml looks god so far. We will dig into the ORMSupport-sources some deeper...
best regards, yves
Joined: 06-May-2008
Joined: 08-Oct-2008
Joined: 06-May-2008
DuenowY wrote:
Hi Otis, thanks for the answer. We have a typeconverter and we can read and write the udt without problems.
Interesting 
The problem we had (and have) with saving UDT CLR (it's the CLR part) typed values to sqlserver is that you have to specify the schema/catalog in which the UDT type is located, which is unknown information for the DQE (it has the .NET type but not the udt schema/catalog info)
The problem is: when serializing the entity with the utd to xml and then deserialzing it, the problem occures. The mentioned code seems not to recognize to use the typeconverter for the type but assumes it to be a string.
Typeconverter works UDT works serializing works fine deserializing doesnt work.
we didn't manually change 'things' (aehm, depends what you mean with 'things' though).
Best regards, yves
'things' as in: manually changed generated code, which could lead to problems, as you might overlook a spot
XML as you know works only with strings. So a type has to be convertable to a string and back. The type converter is not used here, as the type converter is for database interaction and isn't known at the entity level (xml serialization is done at the entity level, it has no idea that a type converter is present). The build-in system is a bit limited in that it can only work with types which are known (string, byte, int etc.). The problem is: what to call to convert the string back to the object it really represents? The only way I see it if it checks in XmlValueToObject if the realType instance is checked for an instance of op_Explicit using reflection. As this is always a static/public method it should not give any problems. If the op_Explicit(string) method is present, it then could call the method and get a normal object back instead of the string method.
The downside is that this will slow down the process of deserialization, though as the check is the last resort, it won't be noticable that much.
So in short: your ToString() implementation on the UDT CLR type should give the string which is passable to the implicit operator implementation of the UDT CLR type to get an instance back.
I'll do some tests with this to see if this is usable. We do have a different system in place for properties added manually to serialize to XML but as your field is an entity field, it's always taken into account and you will always run into this problem.
(edit) I saw I had slightly outdated sources when I built the one I attached (a linq related fix wasn't rolled into this built). I'll update the attachment a.s.a.p. Fixed.
ALmost there. I could reproduce it and fixed the original null ref issue (which was caused by a lame type -> string -> type conversion which failed and which was unnecessary anyway), I now have to implement the explicit operator on the test udt and check whether this fixes the problem.
(edit) works! 
[Test]
public void UDTXmlDeserializationTest()
{
UdtTestEntity udt = new UdtTestEntity(1);
using(DataAccessAdapter adapter = new DataAccessAdapter())
{
Assert.IsTrue(adapter.FetchEntity(udt));
}
Assert.IsNotNull(udt.Udtfield);
string xml;
udt.WriteXml(XmlFormatAspect.Compact25 | XmlFormatAspect.DatesInXmlDataType | XmlFormatAspect.MLTextInCDataBlocks, out xml);
UdtTestEntity deserializedUdt = new UdtTestEntity();
deserializedUdt.ReadXml(xml);
ComplexNumber c = deserializedUdt.Udtfield;
Assert.AreEqual(udt.Udtfield, c);
}
I'll attach a build to this post for you to test (so remember: ToString() returns a string to be placed into the XML and the op_Explicit(string) implementation on the UDT converts it back to an UDT type.
(edit) attached (and now the right one)
Joined: 06-May-2008
Joined: 06-May-2008
Joined: 06-May-2008
Hi,
we changed the code like this (maybe also useful for you):
private static readonly Dictionary<Type, MethodInfo> _udtParseMethods = new Dictionary<Type,MethodInfo>();
public static void CopyEntityValues<T>(T received, T current, Func<T,EntityField2,bool> canCopy)
where T : EntityBase2, IEntity2
{
PersonUtilities.MarkEntityAsReadable(received);
List<IEntityField2> pks = current.Fields.PrimaryKeyFields;
foreach (EntityField2 f in received.Fields)
{
EntityField2 ownfield = (EntityField2)current.Fields[f.FieldIndex];
if (current.IsNew || !pks.Contains(ownfield))
{
if ((canCopy == null) || canCopy(current, ownfield))
{
current.SetNewFieldValue(ownfield.FieldIndex, ConvertValue(f.CurrentValue, f.DataType));
}
}
}
}
private static object ConvertValue(object value, Type type)
{
if (type.GetCustomAttributes(typeof(Microsoft.SqlServer.Server.SqlUserDefinedTypeAttribute), true).Count() > 0)
{
MethodInfo parseMethod = null;
lock (((ICollection)_udtParseMethods).SyncRoot)
{
if (!_udtParseMethods.TryGetValue(type, out parseMethod))
{
parseMethod = type.GetMethod("Parse");
if (parseMethod == null)
{
throw new NotImplementedException(type + ".Parse");
}
_udtParseMethods.Add(type, parseMethod);
}
}
return parseMethod.Invoke(null, new object[] { (SqlString)value.ToString() }); // sure now it exists....
}
return value;
}
Well, this works now
Our tests now run, except one. we get a Null-Ref-Exception at SD.LLBLGen.Pro.ORMSupportClasses.FieldUtilities.DetermineRealType(Type toConvert, Boolean unWrapNullableType), we can bypass this at that point, though (we only need the primary keys of those entities in our case.) Maybe its the same error like the one at the beginning of the thread, but in another method.
Fehler Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt. bei SD.LLBLGen.Pro.ORMSupportClasses.FieldUtilities.DetermineRealType(Type toConvert, Boolean unWrapNullableType)
bei SD.LLBLGen.Pro.ORMSupportClasses.FieldUtilities.DetermineRealFullTypeName(Type toConvert, Boolean unWrapNullableType)
bei SD.LLBLGen.Pro.ORMSupportClasses.XmlHelper.XmlValueToObject(Type realType, String xmlValue)
bei SD.LLBLGen.Pro.ORMSupportClasses.EntityFields2.ReadXml(XmlNode fieldsElement)
bei SD.LLBLGen.Pro.ORMSupportClasses.EntityBase2.Xml2Entity(XmlNode node, Dictionary2 processedObjectIDs, List1 nodeEntityReferences)
bei SD.LLBLGen.Pro.ORMSupportClasses.EntityCollectionBase21.Xml2EntityCollection(XmlNode node, Dictionary2 processedObjectIDs, List1 nodeEntityReferences)
bei SD.LLBLGen.Pro.ORMSupportClasses.EntityCollectionBase21.ReadXml(XmlNode node, XmlFormatAspect format)
bei SD.LLBLGen.Pro.ORMSupportClasses.EntityCollectionBase2`1.ReadXml(String xmlData)
bei LF.Components.Winapo.Personen.Admin.Connect.TransferPersonSerializer.StringToTransferPersonCollection(String personen)
After all, thanks so far for your support, quite interessting to handle udt with llblgen . We will use the provided assembly until the fix made it to the next Build / Release.
Keep up the good work, we love llblgen with it's linq support and were looking forward to v3.0!
DuenowY wrote:
Hi,
we changed the code like this (maybe also useful for you):
private static readonly Dictionary<Type, MethodInfo> _udtParseMethods = new Dictionary<Type,MethodInfo>();
public static void CopyEntityValues<T>(T received, T current, Func<T,EntityField2,bool> canCopy) where T : EntityBase2, IEntity2 { PersonUtilities.MarkEntityAsReadable(received); List<IEntityField2> pks = current.Fields.PrimaryKeyFields; foreach (EntityField2 f in received.Fields) { EntityField2 ownfield = (EntityField2)current.Fields[f.FieldIndex]; if (current.IsNew || !pks.Contains(ownfield)) { if ((canCopy == null) || canCopy(current, ownfield)) { current.SetNewFieldValue(ownfield.FieldIndex, ConvertValue(f.CurrentValue, f.DataType)); } } } } private static object ConvertValue(object value, Type type) { if (type.GetCustomAttributes(typeof(Microsoft.SqlServer.Server.SqlUserDefinedTypeAttribute), true).Count() > 0) { MethodInfo parseMethod = null; lock (((ICollection)_udtParseMethods).SyncRoot) { if (!_udtParseMethods.TryGetValue(type, out parseMethod)) { parseMethod = type.GetMethod("Parse"); if (parseMethod == null) { throw new NotImplementedException(type + ".Parse"); } _udtParseMethods.Add(type, parseMethod); } } return parseMethod.Invoke(null, new object[] { (SqlString)value.ToString() }); // sure now it exists.... } return value; }Well, this works now
Hmm. Still strange why this is needed. The property set caused the same problem? The reason I ask is that it seems that the value you pass into SetNewFieldValue is indeed a string and not an object of your CLR UDT type.
(btw, EntityFields2 has a clone method )
Our tests now run, except one. we get a Null-Ref-Exception at SD.LLBLGen.Pro.ORMSupportClasses.FieldUtilities.DetermineRealType(Type toConvert, Boolean unWrapNullableType), we can bypass this at that point, though (we only need the primary keys of those entities in our case.) Maybe its the same error like the one at the beginning of the thread, but in another method.
Fehler Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt. bei SD.LLBLGen.Pro.ORMSupportClasses.FieldUtilities.DetermineRealType(Type toConvert, Boolean unWrapNullableType) bei SD.LLBLGen.Pro.ORMSupportClasses.FieldUtilities.DetermineRealFullTypeName(Type toConvert, Boolean unWrapNullableType) bei SD.LLBLGen.Pro.ORMSupportClasses.XmlHelper.XmlValueToObject(Type realType, String xmlValue) bei SD.LLBLGen.Pro.ORMSupportClasses.EntityFields2.ReadXml(XmlNode fieldsElement) bei SD.LLBLGen.Pro.ORMSupportClasses.EntityBase2.Xml2Entity(XmlNode node, Dictionary
2 processedObjectIDs, List1 nodeEntityReferences) bei SD.LLBLGen.Pro.ORMSupportClasses.EntityCollectionBase21.Xml2EntityCollection(XmlNode node, Dictionary2 processedObjectIDs, List1 nodeEntityReferences) bei SD.LLBLGen.Pro.ORMSupportClasses.EntityCollectionBase21.ReadXml(XmlNode node, XmlFormatAspect format) bei SD.LLBLGen.Pro.ORMSupportClasses.EntityCollectionBase2`1.ReadXml(String xmlData) bei LF.Components.Winapo.Personen.Admin.Connect.TransferPersonSerializer.StringToTransferPersonCollection(String personen)After all, thanks so far for your support, quite interessting to handle udt with llblgen
This can only be caused by the fact that a type specification is null. Could you provide details so we could try to reproduce this?
Also, could you provide the details how you are able to save an UDT CLR typed value into a row without specifying the catalog/schema name of the UDT CLR type?
Keep up the good work, we love llblgen with it's linq support and were looking forward to v3.0!
(edit) If I could give you a tip: if possible, choose another type than the UDT CLR type, simply because updating UDT CLR types and assemblies is a nightmare. Just a FYI
Joined: 06-May-2008
Joined: 06-May-2008
Joined: 06-May-2008
Joined: 06-May-2008
You're right, the explicit operator is needed for the deserialization to work .... from and to string ....
public static explicit operator string(Schedule value) { return value == null ? null : value.ToString(); }
public static explicit operator Schedule(string value) { return value == null ? null : Schedule.Parse(value); }
See http://msdn.microsoft.com/en-us/library/ms131082.aspx:
The UDT must contain a public static (or Shared) Parse method that supports parsing from, and a public ToString method for converting to a string representation of the object.
Btw, the compiler checks the existance of the UDT's method Parse.
I still don't get the designer to show me the correct .net type (the assembly is in the GAC, sqlserver is on the same machine) without using the type converter, but it always shows the correct UDT name, is that what you mean with 'the UDT CLR type' ?
When the DQE creates a Sqlparameter to save the value to the DB, it has to specify the catalog/schema/T-SQL name of the UDT CLR type but that's unknown information, hence the UDT CLR typed fields are readonly.
Yeah storing the data in a nvarchar field is an idea, but i really need those two methods HasTriggerAt and HasTriggerBetween 
(thought it would be better for performance if the content of this field isn't always parsed if not needed...)
DuenowY wrote:
You're right, the explicit operator is needed for the deserialization to work .... from and to string
public static explicit operator string(Schedule value) { return value == null ? null : value.ToString(); }
public static explicit operator Schedule(string value) { return value == null ? null : Schedule.Parse(value); }
See http://msdn.microsoft.com/en-us/library/ms131082.aspx:
The UDT must contain a public static (or Shared) Parse method that supports parsing from, and a public ToString method for converting to a string representation of the object.
Btw, the compiler checks the existance of the UDT's method Parse.
Ok, though just the explicit operator FROM string is required for deserialization.
I still don't get the designer to show me the correct .net type (the assembly is in the GAC, sqlserver is on the same machine) without using the type converter, but it always shows the correct UDT name, is that what you mean with 'the UDT CLR type' ?
No, the .NET type should be of 'Schedule' as well. Could you mail me the .dll please? I'll then add it to sqlserver and check whether I can reproduce it.
When the DQE creates a Sqlparameter to save the value to the DB, it has to specify the catalog/schema/T-SQL name of the UDT CLR type but that's unknown information, hence the UDT CLR typed fields are readonly.
Yeah storing the data in a nvarchar field is an idea, but i really need those two methods HasTriggerAt and HasTriggerBetween
If you're not doing any CLR code inside sqlserver, it's of no real use as you can then also do it using a normal .NET type and a type converter. (as the field in the DB is then just a string)