Currently when adding an entity via a transaction we always look up the cluster to which to save by trying to find a class with the same name as the entity (C#) type.
That is not necessarily what the user wants. For example some users might simply want to use a generic dictionary-type entity that can hold records of any class.
As a solution I suggest that in BinaryOrientDBTransaction.AddToRecords(), when we don't have an ORID and we resolve the cluster we should check if the entity has an OClassName. If that has been set then we resolve using that. If not we fall back to resolving by the entity's type name.
Copied from original issue: orientechnologies/OrientDB.Net.ConnectionProtocols.Binary#2
weizensnake
commented
6 years ago
From @weizensnake on August 2, 2017 21:31
Currently when adding an entity via a transaction we always look up the cluster to which to save by trying to find a class with the same name as the entity (C#) type. That is not necessarily what the user wants. For example some users might simply want to use a generic dictionary-type entity that can hold records of any class.
As a solution I suggest that in BinaryOrientDBTransaction.AddToRecords(), when we don't have an ORID and we resolve the cluster we should check if the entity has an OClassName. If that has been set then we resolve using that. If not we fall back to resolving by the entity's type name.
Copied from original issue: orientechnologies/OrientDB.Net.ConnectionProtocols.Binary#2