I am in Mongo-C# environment and we have been coding against Mongo for a while using Mongo 1.3.x DLL. Recently, I updated it to be 1.4.2 and everything else was fine until I faced a problem where I noticed that while previous version of Mongo DLL was treating
update.SetWrapped(property.Name, value);
all file when value was null but the recent version does not like it and it throws nullreference exception.
Problem here is that I would like it to be able to accept Null values. has anybody faced this problem before? If yes, how did you handle that?
There was a breaking change when this was introduced. You need to use BsonNull.Value for this. So, your code would look like this:
update.SetWrapped(property.Name, BsonValue.Create(value) ?? BsonNull.Value);
I believe you should have been able to pass C# null to Update.SetWrapped<T> because T is a POCO and not a BsonValue and the serializer for T would decide how to serialize C# null.
I've created a JIRA ticket for this:
https://jira.mongodb.org/browse/CSHARP-486
Note that while C# driver versions earlier than 1.4 did not throw a NullReferenceException, they also did not update the property to BSON null as you might have expected (passing C# null to SetWrapped turned the SetWrapped into a no-op in earlier versions).
The basic rules for C# null handling are clear:
C# null is not a valid BsonValue, use BsonNull.Value instead
C# null is valid for POCOs, and will probably be serialized as a BSON null (although technically a serializer for a POCO could choose a different representation)
Related
I've been plagued for months with an error in ODM.
It doesn't prevent my services from working, it only prevents ODM from automatically generating the JSON input payload when I test a service through the Rule Execution Server (the Retrieve HTDS Description File).
I attached a screenshot of the error.
What is puzzling is that:
if I move my variable from Input to Output, then the JSON gets generated in the Server Response section
if I manually enter my own JSON, the service executes correctly and I get back a decision
Does anyone have any idea what could possibly be wrong here?
Very likely your variable is not being deserialized properly. This would explain both the error you are getting and why you get it only as an input variable.
We get a similar error using a java.tim.ZonedDateTime with ODM 8.9.1, which does not support the java.time package. We just ignore the error -- and are hoping we can avoid it when we move to ODM 8.10.2.
hard to help as some of the context is missing. However the symptoms you describe tells there is a serialization issue one of the class of the HTDS interface.
It could be :
a getter/setter missing
a dependency missing in the XOM (classloader)
or a #jsonIgnore missing on a non getter/setter method whose name starts by get or set.
Best
Emmanuel
We have just upgraded some software we have from ServiceStack 4.0.62 to ServiceStack 5.0.0.0.
For some reason ormlite's encoding management seem to have changed.
Code that simply saves a DTO with a string field containing special characters (e.g Ø ← ↑ → ↓ ↔ ↕~ Σ ∂ φ) that used to work in 4.0.62 now saves ? in the DB.
Has anything changed that could cause that breaking change. We did not change the save code, and breakpoint just before save clearly shows the correct characters.
This is basicaly the code we are executing:
DB.Save<DTOType>(dtoInstance)
I was going through ServiceStack ORMlite code and found out about this:
OrmLiteConfig.DialectProvider.GetStringConverter().UseUnicode;
So I trying that calling
OrmLiteConfig.DialectProvider.GetStringConverter();
just before the DB.Save call returned false, which would explain the issue, as this would set the dbCmd to use VARCHAR instead of NVARCHAR
I set
var stringConverter = OrmLiteConfig.DialectProvider.GetStringConverter();
stringConverter.UseUnicode = true;
at AppHost initial configuration and that fixed the issue.
Apparently I cannot read documentation properly as it was described here
https://github.com/ServiceStack/ServiceStack.OrmLite/wiki/OrmLite-Type-Converters
The major change that may have affected this is switching to paramaterized queries in v4.0.60. OrmLite typically itself doesn't do any encoding for normal string properties, i.e. it just passes the string value into the ADO.NET DB parameter.
The main time it transforms strings values is when it serializes complex types into blobs.
The issue may be end up being in using an upgraded version of the ADO .NET provider.
We have been building our application using groovy 2.3.6. Now because of some platform level issues we are advised to downgrade our groovy version to 2.2.1. I am facing no. of issues regarding this downgrade.
groovy is not able to infer the type of it variable in ver 2.2.1 so if i have code something like this
names.any { sliceName.endsWith(it) }
it gives me exception
[Static type checking] - Cannot find matching method java.lang.String#endsWith(java.lang.Object)
Secondly all the default method that i had used in collections no longer seem to exist
positions.any { it.primary }
groovy is unable to find the any method on list.
One way would be turn off static type checking, which will expose the code to a lot more runtime errors.
Is there any way to resolve these errors, without turning off static type checking. Also are these features only added in groovy 2.3.6 like default groovy methods and type inference for it variable
If you go back to an old version, old bugs will bite you.
Try giving the static compiler more of a hint
names.any { String it -> sliceName.endsWith(it) }
I replaced all of my JNDI lookups with JNDI.lookup() method because it seemed convenient, dealt with dynamic return types, etc. All was great...but now I just noticed that the checked exceptions that I had to catch before are no longer there.
I assumed this was because it would have just returned null if the JNDI variable didn't exist but it doesn't. It now just throws an unchecked exception.
Any idea why? Is there a way of just returning null for non-existant variables instead?
I created a bug for this on the omnifaces website: https://github.com/omnifaces/omnifaces/issues/141
Not sure if this is intended behavior or not.
Is there a way of just returning null for non-existant variables instead?
It does that for NameNotFoundException. The problem was here not in OmniFaces, but in the environment, which was GlassFish 4.1 in your specific case. It unexpectedly wrapped the NameNotFoundException in another NamingException, hereby causing the underlying NameNotFoundException to slip through and bypass the return null condition.
This has been fixed with help of Exceptions#is() utility method as per this comment. It will be available in OmniFaces 2.2.
I am having trouble with Subsonic 3.0 generating an object for a table which contains the new HeirachyID datatype. From what I have found, there is no corrosponding .Net type, and subsonic doesn't seem to know how to handle the hierachyid data.
Error that is thrown:
Object of type 'Microsoft.SqlServer.Types.SqlHierarchyId' cannot be converted to type 'System.String'.
Code:
foreach (MyDB.DataAccess.ThingCategory tc in DataAccess.ThingCategory.Find(x => x.fk_Thing.Equals(thingId)))
{
sb.AppendFormat("<{0}>{1}</{0}>", wrapTag, tc.Categories.ToList<DataAccess.Category>()[0].Name);
}
tc.Categories.ToList() generates the error
Alternatively, I tried to get around this by writing a sproc to return the hierachyid column as a string, and noticed SubSonic 3.0 sprocs are not strongly-typed. or am I doing something wrong?
Sprocs can be strongly-typed by calling ExecuteTypedList()
I would create an issue on the Github tracker to either add support for the type (someone will have to contribute this since I don't think it's a high priority) or to gracefully handle it when they exist.