We currently have an object that has BSon value types as properties.
When trying to use NEST (instead of elasticsearch.net) we get a serialization exception on AsBoolan property, which is part of the BsonValue type.
How should I use NEST when a type has BSon types.
Specifically we use a BSonDocument to have dynamic properties.
Thanks,
Ron
Related
In JsonDeserialize annotation documentation the contentAs field is supposed to define the "Concrete type to deserialize content".
I tried to use this in combination, with either a Converter (via contentConverter field of the same annotation) or a JsonDeserializer (via contentUsing field of the same annotation), by extending either StdConverter or StdDeserializer, respectively, in an attempt to create an agnostic custom deserializer.
I cannot find a way to access the JsonDeserialize#contentAs information inside any of these two classes.
I am aware that the classes I extend from have a type parameter, I just put an Object class there. Documentation states
contentAs Concrete type to deserialize content (elements of a Collection/array, values of Maps) values as, instead of type otherwise declared. Must be a subtype of declared type; otherwise an exception may be thrown by deserializer.
Apparently I am applying the #JsonDeserializer annotation on a Collection of some persistable Class. I want to deserialize each such object, solely by knowing its id. Well, if I could only get that very type I defined in the #JsonDeserializer#contentAs field...
Can anyone tell me if this is possible anyhow?
I managed to implement the agnostic deserializer withou the use of #JsonDeserializer#contentAs after all.
After reading the javadocs of com.fasterxml.jackson.databind.JsonDeserializer I concluded that my custom deserializer should implement the com.fasterxml.jackson.databind.deser.ContextualDeserializer interface.
Inside the implementation of ContextualDeserializer#createContextual(DeserializationContext ctxt, BeanProperty property)
I could finally get access to the class type of the content of the collection, which I applied the #JsonDeserialize annotation on,
by calling:
ctxt.getContextualType().getRawClass()
NOTE that the same call inside the implementation of com.fasterxml.jackson.databind.JsonDeserializer#deserialize(com.fasterxml.jackson.core.JsonParser, com.fasterxml.jackson.databind.DeserializationContext) returned null, hence the need of the aforementioned interface.
All I had to do then is store the returned class in a member field (of type Class< ? >) of the custom deserializer and use it in the execution of JsonDeserializer#deserialize()
The only thing that remains to check is whether an instance of this custom deserializer is shared between threads. I only did some minor checks; I used the same implementation for two different collections of different types. I observed that ContextualDeserializer#createContextual(DeserializationContext ctxt, BeanProperty property) was called once (among multiple deserialization invokations), for each distinct type that was going to be deserialized. After checking during debugging, it seems that the same deserializer object is used for the same type. In my case, since what I store in the member field is this type itself, I don't mind if the same deserializer is used for the same java type to be deserialized because they should contain the same value. So we 're clear on this aspect as well.
EDIT: It appears all I have to do is update the com.fasterxml.jackson.databind.deser.std.StdDeserializer#_valueClass value to the now known class. Since it is final and since the ContextualDeserializer#createContextual(DeserializationContext ctxt, BeanProperty property) returns a JsonSerializer object, which is actually used,
instead of returning "this" serializer I can create a new one, passing the discovered class in the constructor, which actually sets the StdDeserializer#_valueClass to the class I actually want, and I'm all set!
Finally, NOTE that I didn't have to use the #JsonDeserializer#contentAs annotationfield as I get the value from the ctxt.getContextualType().getRawClass() statement inside ContextualDeserializer#createContextual(DeserializationContext ctxt, BeanProperty property) implementation
I'm trying to understand something about type properties in swift.
The Swift Programming Language says
For classes, you can define computed type properties only
So a computed property does not store a value itself, but it is calculated. That I understand. But I don't get how such a thing can apply to type properties. Such properties belong to the class itself and not to an instance of it.
So if you use a getter for such a computed type property, what could you possibly use to calculate it? It can't be any other type properties, as they too can only be computed properties. You would get a sort of loop of computed properties because there aren't any stored type properties.
In the same way, I also don't get what a setter would do. If you call the setter of a computed type property, what can it set? There are no stored type properties to be set.
Bear in mind that stored class properties are only unsupported at the moment. The compiler error you get when you try to use them—"Class variables not yet supported"— suggests that they're on their way. Computed class properties don't necessarily have to make sense on their own.
However, computed properties don't always have to be based on the values of stored data. As it stands, you could use them for "static" read-only values associated with the class, say:
class var ThisIsAClassConstant: String { return "Woo" }
And people have already come up with ways to store associated values, for example, in the first two singleton patterns in this answer, the class property stores its state in either a global (but private) variable, or in a static variable inside a nested structure.
These are obviously a bit "workaroundy", but they're a way of achieving class-like storage while it's not officially implemented.
I remember coming across some way to declare multiple Set handlers in a property but now I can't figure out how it's done. It's useful in that one can assign different data types and the Set handler does the conversion, but I get the error
'Set' is already declared
thoughts anyone?
It's not possible
It would be nice to be able to write both
sQuantity = "1234"
and
sQuantity = 1234
with two setter functions, but trying to write even one setter function with the wrong parameter type seems doomed to failure:-
error BC31064: 'Set' parameter must have the same type as the containing property.
If Visual Basic doesn't allow conversion between setter parameter type and property type then there is no way it would be possible to have two setter functions. If setter functions are forced to have the same type as the property, then it could not know which to run if there were more than one!
So I'd argue 'not only does it not seem possible, but it is actually not possible!'
There is a workaround
What you can do however, is have two properties of different types changing the same underlying variable, so that you can write
sQuantityFromString = "1234"
and
sQuantityFromInt = 1234
using
Public Shared WriteOnly Property sQuantityFromInt () As Integer
with a setter function that takes an integer as a parameter and with both properties setter functions modifying the same underlying string member variable.
Private Shared m_sQuantity As String = Nothing
As far as I know, you cannot have multiple Set statements for a class property. A property cannot be overridden.
You can use a setter functions (this is mostly a paradigm in Java) and overload that if you need to. Then I would also suggest making the property readonly.
One other option is to have the property be defined as an Object and in the set check the TypeOf of the value being used to set the property and do whatever business logic you want. The only problem with this approach is that then your property doesn't have type checking.
I've got a piece of code in a project (MyProject) that contains early bound object from a referenced assembly (We'll call it CommonAssembly):
Dim myObject As CommonAssembly.MyEarlyBoundType
now I have another assembly that is dynamically loaded because it is not present in all projects:
Dim myLateBoundObject As Object = AppDomain.CurrentDomain.CreateInstanceAndUnwrap("Utils", "Utils.MyLateBoundType")
MyLateBoundType derives from CommonAssembly.MyEarlyBoundType, and I want to cast myObject to myLateBoundObject and then programmatically invoke the additional member methods
via reflection.
I'd have thought that by extracting the type of myLateBoundOject and casting myObject into myLateBoundObject, that'd work, but both CType() and DirectCast() methods won't accept the extracted type citing a "Keyword does not name a type" error:
myLateBoundObject = DirectCast(myObject, GetType(myLateBoundObject))
I'm not entirely sure why a dynamically loaded type cannot be used against the DirectCast (pretty sure it's not type saftey checked?) method, since if Utils.MyLateBoundType was referenced in "MyPrjoect", I could execute:
myLateBoundObject = DirectCast(myObject, Utils.MyLateBoundType)
without any problems - but this is not a dynamic solution.
Any suggestions?
Cheers,
Yum.
Yeah, that's not going to work like that. Any attempt you'd make in your code to cast to the dynamically loaded type will make your program have a non-dynamic dependency on the assembly.
You should use an interface type. Declare that type, with all the properties and methods you'd want to have available in your main program, in a separate assembly. Both your main program and your plug-in will have a dependency on it. The dynamic type should inherit it to provide the implementation. You can now cast the return value of CreateInstance to that interface type.
Ok so I'm trying to use the JavaScriptSerializer to work with this code. However it crashes when it reaches the last line;
Dim json As New String(sr.Serialize(dt))
I get this error message;
A circular reference was detected
while serializing an object of type
'System.Reflection.Module'.
I would really appreciate any insights that could help solve this problem.
Circular reference means that serialising the object would result in an infinite loop.
For example if you would try to serialize object "A" having a 1 to 1 reference to object "B".
Declare a class containg the data you want to serialize with JSON to solve this issue.
As hkda150 has already said, you could use a class specifically tailored for being serialized.
This will furthermore enable you to have foreign key values serialized instead of having related full objects serialized. Thus, if you are serializing object a which has a property a.SomeB of type B, then you will often want the ID of a.someB to be present in your webpage. Obviously I don't know enough to be able to say if this is relevant in your specific use case.
BTW, If you find yourself doing a lot of mapping between "business objects" and "objects meant for serialization" you may want to consider using AutoMapper.