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.
Related
context: I'm adding a new resource to TF Provider.
I've got an API that optionally return a string attribute so I represent it as:
"foo": {
Type: schema.TypeString,
Computed: true,
Optional: true,
},
Question: if an API returns value not set / empty string for response.foo, shall I still set an empty string for foo attribute or I shouldn't set any value instead (e.g., null)?
in my resource schema.
(Hello! I'm the same person who wrote the answer you included in your screenshot.)
If both approaches -- returning null or returning an empty string -- were equally viable from a technical standpoint then I would typically prefer to use null to represent the absence of a value, since that is clearly distinct from an empty string which for some situations would otherwise be a valid present value for the attribute.
However, since it seems like you are using the old SDK ("SDKv2") here, you will probably be constrained from a technical standpoint: SDKv2 was designed for Terraform v0.11 and earlier and so it predates the idea of attributes being null and so there is no way in its API to specify that. You may be able to "trick" the SDK into effectively returning null by not calling d.Set("foo", ...) at all in your Create function, but there is no API provided to unset an attribute and so once you've set it to something non-null there would typically be no way to get it to go back to being null again.
Given that, I'd suggest it better to be consistent and always use "" when using the old SDK, because that way users of the provider won't have to deal with the inconsistency of the value sometimes being null and sometimes being "" in this case.
When using the modern Terraform Plugin Framework this limitation doesn't apply, because that framework was designed with the modern Terraform language in mind. You aren't using that framework and so this part of the answer probably won't help you right now, but I'm mentioning it just in case someone else finds this answer in future who might already be using or be considering use of the new framework.
I've been banging my head on this problem for a week, and now I'm starting to understand what's going on, but no idea why, or how to fix it.
Let me describe what I'm doing. I have an assortment of various objects in Java, and I have a native library. Java objects inform the library of their existence by calling NativeLibrary.AddObject(this). The native library has a container of jobjects where I store global references to the Java objects, obtained with env->NewGlobalRef(object). The native library uses these stored references to access the Java objects, and it does work fine.
And here's the crucial part that does NOT work. Obviously, I want to be able to delete Java objects, not only add them. So, when a Java object is no longer needed, it calls NativeLibrary.RemoveObject(this). The native library implements it by iterating the list of stored objects (which are all global references, as you may remember) and finding a match with env->IsSameObject(passedObject, storedObjectGlobalReference).
And here's where the problem is: it doesn't work as expected, the Java objects are not matched to their global references properly. When I started digging and logging all the calls with all the parameters, I noticed a weird thing: the jobject parameter of the native call (which is this of Java objects) has the same value for different objects! Moreover, this value changes between the ``NativeLibrary.AddObject(this)andNativeLibrary.RemoveObject(this)` calls for the same object!
So, what's going on, and how can I store, keep track of and delete the references to Java objects in native code? To reiterate: everything works fine as long as I only create and store global refs; the correct objects receive notifications via these refs, no problem. But as soon as I try deleting these references via env->DeleteGlobalRef, I find out that in the NativeLibrary.RemoveObject(this) implementation fails to match the stored reference to the passed jobject.
I was with the same problem. The root cause was that the added item NativeLibrary.AddObject(this) not was the same object when I called NativeLibrary.RemoveObject(this). I was using junit and this was causing the problem, because junit create multiples objects to run each test. I found the problem using System.out.println with the object in Java side. Before add function System.out.println("add object: " + sameObject); and before remove function System.out.println("remove object: " + sameObject);. Sorry for poor english, I hope this help someone.
I tried it with PostgreSql provider. Digging into code I see that:
OrmLiteDialectProviderBase.ToCreateTableStatement() method strangely always passes null as scale parameter to GetColumnDefinition().
PostgreSQLDialectProvider.GetColumnDefinition() ignores all parameters except fieldType
Is this intended to be so? Is there a workaround to make CreateTable consider fields length?
P.S. Is there an active issue tracker for ServiceStack? Link at https://github.com/ServiceStack/ServiceStack/wiki/How-to-contribute is broken.
I've been a little surprised, because I have read before, that __gc metamethod is only called for userdata and never for tables. (LuaFAQ : Why don't the __gc and __len metamethods work on tables?)
But, recently, I have tried it and found it actually works! Try this code with Lua 5.2.1:
do
local b = setmetatable({a = 1}, {__gc = function(self) print(self.a); end});
end
collectgarbage();
But I can't find anywhere the changelog for this, so I'm little frustrated and afraid to use it.
Maybe, someone can prove my suggestion? Or it is an undocumented behaviour?
As for me it will be nice to have a regular way to create table destructor, and I will be glad if my observation is right.
The Lua 5.2 Reference Manual section 2.5.1 indicates that tables do support the __gc metamethod. Specifically, it says
For an object (table or userdata) to be finalized when collected, you must mark it for finalization. You mark an object for finalization when you set its metatable and the metatable has a field indexed by the string "__gc".
The similar documentation in the 5.1 Reference Manual says
Using the C API, you can set garbage-collector metamethods for userdata
It seems pretty clear that Lua 5.2 now explicitly supports the __gc metamethod for tables.
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)