Page History

...

Installing and configuring an Ignite 3 cluster with similar configurations/topology as topologies to an existing Ignite 2 cluster is out of outside the scope of this document.

...

This feature will be offered as a CLI tool which that will roughly follow this process:

...

This component must use a stripped-down version of Ignite 2 to read the persistence files without starting a full cluster. For instance, the network capabilities of Ignite are not required for this use case. The StandAloneGridKernalContext provides an example of a stripped-down version of the AI2 GridKernalContext, which can be used as a reference implementation.

...

We have identified the following cache configuration scenarios:

Scenario 0:

• Cache has just one Query Entity (QE)
• All the records (CacheDataRows/BinaryObjects) have exactly the same attributes (Columns) as defined in the  Query Entity (QE).
• All the record’s attributes are valid SQL Native types.

Scenario 1:

• Cache with no Query Entity (QE) defined.

Scenario 2:

• Cache with multiple Query Entities defined.

Scenario 3:

• Cache with a single Query Entity (QE) defined.
• Some records do not match the defined Query Entity (QE). These records might have additional attributes or miss some attributes defined in the QE. Additionally, the record attributes might not be compatible with the datatype defined in the QE or might not be a valid SQL Native type. For example, the Organization’s cache in the examples. 

Given each scenario, the SQL generator must:

Scenario 0: 

• Directly map to the table schema every attribute (name/type/constraints) from the original QE.
• When the QE the Key or Value are simple native Java (int, long, String, etc.) they will not likely have an explicit field name in the QE. In this case, the field name should be selected from a list of candidates, ensuring that the selected candidate does not collide with an explicitly defined attribute name.

Scenario 1:

• Define a table with two Binary attributes (ID: byte[], VAL: byte[]), where the . The attribute names should be the first candidates from the list since there are no other fields to cause collisions.
• The topic of mapping complex objects to byte arrays is slightly more complex. The easiest and most versatile approach would be to serialize the Objects in the CacheDataRow. We should use a widely available serialization format like JSON to make sure that custom client applications can easialy easily access them. In step 4 we'll need to convert binary objects to JSON and store thatthe JSON string.

Scenario 2: 

• AI3 doesn't support this directly, and this is very rare and frowned upon even in AI2. We can safely leave this unsupported until someone asks us to support thisit.

Scenario 3: 

• Generate the table schema according to the same algorithm as Scenario 0.
• Unfortunately, there is no static method to ensure that all the records comply with the Query Entity (QE). We may implement a `dry-run` operation mode to assert this without moving data. Albeit, this would probably be an expensive operation as well.

The SQL Generator should also be exposed as a separate CLI command , to enable the client to manually tune the table schema before migrating data.

...

The mapping between CacheDataRows and Ignite 3 Tuples can be done in two steps. First, the CacheDataRow key and value (KeyCacheObject and CacheObject) must be adapted into a tuple. This can be easily done after analyzing the CacheObject implementation. For BinaryObjectImpl instances, it is very easy to map the Row field names by retrieving the the BinaryObjectImpl ‘rawType’. On the other hand, native Java types might not have a defined field name in the CacheObject, as discussed previously. In this case, we can map its value to a placeholder and resolve the actual field name in the next step.

...

Migrate Persistent Cache

Parameters

Generate SQL DDL Script

...