ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vladimir Ozerov (JIRA)" <j...@apache.org>
Subject [jira] [Created] (IGNITE-1519) Introduce Ignite type configuration.
Date Mon, 21 Sep 2015 10:48:04 GMT
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

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],
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.

Simplify and unify Ignite types system to make it more user-friendly. 

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

*Raw design proposal*:
1) Define a new property in IgniteConfiguration "typesConfiguration" accepting collection
of objects "TypeConfiguration".
2) TypeConfiguration structure:
name           : String
fields         : Map<String, Type>
affKeyField    : String
portableConfig : TypePortableConfig
dotNetConfig   : TypeDotNetConfiguration
"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

View raw message