Vladimir Ozerov created IGNITE-1519:
---------------------------------------
Summary: Introduce Ignite type configuration.
Key: IGNITE-1519
URL: https://issues.apache.org/jira/browse/IGNITE-1519
Project: Ignite
Issue Type: Task
Components: general
Affects Versions: 1.1.4
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
Priority: Critical
Fix For: ignite-1.5
*Problem*:
Ignite has sophisticated type configuration defined in classes
[CacheTypeMetadata|https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/cache/CacheTypeMetadata.java],
[CacheTypeFieldMetadata|https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/cache/CacheTypeFieldMetadata.java],
[org.apache.ignite.cache.query.annotations|https://github.com/apache/ignite/tree/master/modules/core/src/main/java/org/apache/ignite/cache/query/annotations].
We are planning to add portable and platform features. Portables will have
their own configuration describing how to find fields in serialized object
without having a class (see
[PortableMarshaller|https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/portable/api/PortableMarshaller.java]
and
[PortableTypeConfiguration|https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/portable/api/PortableTypeConfiguration.java]).
Platforms will also have type configuration which is passed to native platform
to map portable types (see
[PlatformDotNetPortableTypeConfiguration|https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/platform/dotnet/PlatformDotNetPortableTypeConfiguration.java]).
Trying to configure all these stuff will be a nightmare for users.
*Goal*:
Simplify and unify Ignite types system to make it more user-friendly.
*Considerations*:
1) Backward compatibility must be preserved.
2) Four interested parties must be considered: cache queries, JDBC store,
portables, platforms.
3) Per-cache configuration must stay because different caches may need to
interpret the same type differently (e.g. create index in cache A, but do not
do that in cache B).
4) CacheTypeMetadata is essentially a pair of key and value types.
5) PortableTypeConfiguration is configured for either single class or all
classes in some package.
*Raw design proposal*:
1) Define a new property in IgniteConfiguration "typesConfiguration" accepting
collection of objects "TypeConfiguration".
2) TypeConfiguration structure:
{code}
name : String
fields : Map<String, Type>
affKeyField : String
portableConfig : TypePortableConfig
dotNetConfig : TypeDotNetConfiguration
{code}
"name" is type name as it is used everywhere in the system.
"fields" is a map from field name to field type. Must be provided at least if
queries or POJO store is used. When defined, we register them in portable
metadata on startup if type is portable.
"affKeyField" name of affinity key field, used for query colocation and in
portables.
"portableConfig" is what PortableTypeConfiguration currently is.
"dotNetConfig" is platform-specific configuration for .Net, e.g. assembly name.
3) CacheTypeMetadata stay in CacheConfiguration but is simplified, because we
no longer need to define field classes. Normally user will only define several
sets or varargs (not maps!) of field names for indexes and query fields.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
