Interoperability
GigaSpaces offers interoperability between documents and concrete objects via space - it is possible to write objects and read them as documents, and vice versa. This is usually useful in scenarios requiring reading and/or manipulating objects without loading the concrete .NET classes. This page describes how to do it.
Requirements
When working with documents the user is in charge of creating and registering the space type descriptor manually before writing/reading documents. When working with concrete objects the system implicitly generates a space type descriptor for the object's class using attributes or gs.xml
files when the class is used for the first time. In order to inter-operate, the same type descriptor should be used for both concrete objects and documents.
If the object's class is in the application's AppDomain, or the object type is already registered in the space, there's no need to register it again - the application will retrieve it automatically when it's used for the first time. For example:
// Create a document template using the POJO class name:
SpaceDocument template = new SpaceDocument(typeof(MyObject).FullName);
// Count all entries matching the template:
int count = spaceProxy.Count(template);
If the object's class is not available in the classpath or server, the application will throw an exception indicating there's no type descriptor registered for the specified type. In that case, it is possible to manually create a matching type descriptor using the SpaceTypeDescriptorBuilder
and register it in the space. However, that's not recommended since it essentially requires you to duplicate all the concrete object settings and maintain them if the object class changes.
Query Result Type
When no interoperability is involved this is a trivial matter - Querying an object type returns objects, querying a document type returns documents. When we want to mix and match, we need semantics to determine to query result type - Object or Document.
Template Query
Template query result types are determined by the template class - if the template is an instance of a SpaceDocumnet
the result(s) will be document(s), otherwise it will be object(s).
Sql Query
The SqlQuery
class has a QueryResultType
settings which can be set at construction. The following options are available:
Object
- Return .NET Object(s).Document
- Return space document(s).
ID Based Query
In order to support ID queries for documents, use the IdQuery
class, which encapsulates the type, ID, routing and a QueryResultType
with the corresponding ISpaceProxy
overload methods: ReadById
, ReadIfExistsById
, TakeById
, TakeIfExistsById
. The result type is determined by the QueryResultType
, similar to SqlQuery
.
Respectively, to support multiple ids queries, use the IdsQuery
with the corresponding ReadByIds
and TakeByIds
.
Dynamic Properties
By default, type descriptors created from concrete object classes do not support dynamic properties. If a document of such a type with a property that is not defined in the object will be written to the space, an exception will be thrown indicating the property is not defined in the type and the type does not support dynamic properties. In order to have a concrete class support dynamic properties it should have a property decorated with the [SpaceDynamicProperties] and the type of that property must be either DocumentProperties, Dictionary<String, Object> or IDictionary<String, Object>.
[SpaceClass]
public class MyObject
{
private Dictionary<String, Object> _dynamicProperties
[SpaceDynamicProperties]
public Dictionary<String, Object> DynamicProperties
{
get{ return _dynamicProperties; }
set{ _dynamicProperties = value; }
}
}
The storage type of the dynamic properties can be explicitly set in the attribute [SpaceDynamicProperties(StorageType=StorageType.Binary)] (the default is StorageType.Object).
For more details about storage type refer to Property Storage Type