I have a class that instantiates it's own internal objects and changes internal properties on them which aren't serialized. One for example is setting the parent object.
How do you prevent the BSON driver from instantiating these particular members on a class, since the main class for the document already does this?
I have read the serialization information (quite minimal) and checked what BSON attributes are available but I don't see anything that looks like it will help.
To get round my issue I refactored the properties to instantiate what they needed on the object created by the BSON deserialization process.
Related
I would like to get some information on how the serialisation/deserialisation mechanism works in Firestore. The issue I am having is that I am passing a Scala (JVM language) object into the Firestore create method but it blows up at the point of serialising that data. After some investigation, it appears that Firestore requires values created from classes which have an empty public constructor, why is this a constraint? This is something that Scala classes do not have. Is there anyway to side-step Firestore's serialisation and provide my own?
Firestore requires values created from classes which have an empty public constructor, why is this a constraint?
When you load data from Firestore, you have the option to read a Java object from the document by calling DocumentSnapshot.toObject(Class<T> valueType). In order to create the object that it returns, the Firestore SDK must be able to call a constructor on the class that you pass in. And the only constructor it can reasonably call, is one without any arguments, as it has no way to determine what argument values to pass in otherwise.
Note that calling toObject is not the only option to create an object out of a DocumentSnapshot. You can also construct the Java object yourself, and extract the individual values from the snapshot by calling its get methods.
A quick search seems to hint that it is possible to add a no-argument constructor in Scala too, so I also recommend checking out:
Scala case classes with new firebase-server-sdk
A quick overview of using Firebase in a Scala application
I have the class GraphHandler. Inside of superclass I try to handle restoring the object that was last saved into the database. For this I'm using primaryKey.
The point is that a the time of restoring I don't know yet which type should I expect. So I tried with this:
let realm = ClientManager.cacheRealm()
realm.object(ofType: Object.self, forPrimaryKey: "uniqueid")
But I get the error:
Terminating app due to uncaught exception RLMException, reason: 'Object type RealmSwiftObject is not managed by the Realm. If using a custom objectClasses / objectTypes array in your configuration, add RealmSwiftObject to the list of objectClasses / objectTypes.'
Im trying to do it a way that the handler don't need to know in advance which type of object was saved last. What can solve this? I think that implementing generics won't do any good to it as I can't be changed on the fly.
By the time you call the function realm.object, the type of the object needs to be known, since using this function, realm is only searching for objects of a specific type. Moreover, the type of primary key can be different as well, hence the type of object you are looking for needs to be known before querying realm.
Querying all types and filtering afterwards is only not an option at the moment, since Result can only store a single type of objects. However, if you really need to query all types using a single query to get the last database entry regardless of what class it had, have a look at this comment on a related GitHub issue, where Realm engineers give some workaround for the issue.
Another workaround you could try is the following: create a TimeStamps class, which is managed by Realm, has only a single entry in Realm and which has a one-to-one relation to each of your other Realm classes. The object on the other side of the one-to-one relation would always be the object that you added the last time to Realm of that specific class. With this approach, if you are looking for the latest object added to realm, you can use a simple query that retrieves the only TimeStamps object you have and you can filter for the object added last by filtering the one-to-one relations TimeStamps have. Of course for this to work, you need to associate the creation date of your objects with the relationships you are storing in your TimeStamps object and update these relationships in each of your write transactions.
I've yet to use Morphia, but I'm considering it for a current project.
Suppose I have a POJO with a number of #Reference annotations and I ask Morphia to fetch the object graph from the database. If I then make another DAO or DataStore call and ask Morphia to fetch some object that was already instantiated in the first graph, would Morphia return a reference to the already instantiated object or would it create a new instance?
If Morphia returns a new instance of the object each time, does anyone have a recommendation of how to best approach creating a Morphia-backed repository that won't duplicate already-instantiated objects?
As I see it in Morphia, it will re read every reference.
This is one of the problems, why I created Morphium. I integrated a caching layer there, so if you read a reference, this one won't be read again (at least, if you search by ID...)
We use morphia in production and there are two ways to make sure you don't load the references which is something we came across too.
One is to use the lazy loading option when you define the #Reference element in your main class. This of course means that this behavior is 'global' to that object.
The better way to do this is to not define an #Reference using Morphia and instead managing the references yourself. Let me know if you need a code sample.
I've stopped using #Reference too and instead declare something like:
ObjectId itemId
rather than having a field item. This has 2 benefits: (1) it lets me define a getter through a helper getObject(...) method which I have written with object caching and (2) it stores a simple ObjectId in the Mongo object rather than a full DBRef which includes the collection name and thus about twice the data size.
I have a class called Test which has four public properties and one of them is static. the problem is after deserialization the static property contains null value. i have debugged the code and found that at server side it contains the value which is a collection , but at client side it becomes null after deserialization. i know static members doesn't serialize and deserialize so obviously it should contain the value.
Static variables are global and stateful - thus they exist solely in the context of the application, or in other words, memory.
You could pass the value of the static property in another non-static property, but you can't send your application's memory down to the client.
If the static value is initialised when the type is loaded (via a field initialiser or via the type initialiser/static constructor) then it should contain the value.
If however, the server side static value is initialised as a side effect of some method call, then you would have to reproduce this method call on the client as well.
I'm not sure I understand...as you say in your question:
i know static members doesn't serialize and deserialize...
Given that, why would you expect the value from the server to propagate to the client? You will need to find an alternative means of transferring this property (make an instance property, send your own message, etc.)
Remember that static member values exist within a particular .NET application domain, and application domains exist within a particular operating system process.
Given that the server and client are different operating system processes and possibly even different machines, as Adam mentioned, there is no way for the value you had on the server to automatically transfer to the client without you writing some code.
I think maybe there is a misconception - Serialization is not packaging up the instance and its static members on the server, and sending it down to the client. It is extracting the values of the members it regards as serializable (e.g. members annotated with [DataMember], or instance members, but not static members), and sending down only those values to the client.
Therefore the value on the client will be the same as the value on the server was before you set it to the value you're now expecting to see on the client.
However: I notice you also mention you see that a collection of yours has a null value.
If you are using DataContractSerializer in a PartialTrust environment, be aware that it may not call the constructor of your class.
Quote:
When instantiating the target object during deserialization, the DataContractSerializer does not call the constructor of the target object.
If that collection was created by your constructor, this may explain why you see null.
What do you do with classes that have no member data, only methods?
Do you make them static?
In my case it is an repository class that executes queries against the database. Maybe I got the repository pattern wrong... (It does implement an interface)
Inherit from an Interface mean that you cannot use static. Simply create a class and instantiate it.
If it implements an interface, and gets passed around as that interface, then you can't make the members (or the class) static. The interface aspect means that although an instance won't have any actual fields, it still contains valuable information - its type.
You might want to make it a singleton, but there's no particular need to.
Why won't you make a database wrapper class, that maintains the connection to database opened/closed. Moreover, it can also open it automatically if new query is sent. You can include the functions your class has, running them right on the inner pointer to the database.
I guess this is the best database management pattern. If you use it, you should make a Factory method that returns the object of this class initialized on some specific database. Then you pass that object around.
Or if you are lazy and sure that you will need only 1 database, make it a singleton.
It depends. Most of the time it might be possible to make the class static, but sometimes you need to pass an instance of it around. Sounds like you might be having this situation. In this case perhaps you should consider a Singleton pattern, since more than 1 instance of the class is not likely to be needed?