Details
-
New Feature
-
Status: Closed
-
Major
-
Resolution: Fixed
-
0.2
-
None
Description
In order to support ARRAY in gora-cassandra, we have two scenarios as follows:
1) super column family like the current MAP implementation; or
2) single column to store all elements of ARRAY.
Each senario has pros and cons, but I'd prefer 1) and I have implemented a prototype.
1) super column family
-
- pros
- consistent with MAP
- each column stores primitive type value.
- cons
- ARRAY cannot be contained in RECORD or MAP.
2) single column
-
- pros
- complex type such as RECORD and MAP can have ARRAY value.
- cons
- large size of ARRAY requres a huge single column value.
- difficult to implement for STRING and BYTES (variable length).
Currently, super column is used for other complex types such as RECORD and MAP,
so it is consistent to use super column for ARRAY.
Considering this, the rule that complex type cannot have complex type value
seems a reasonable limitation, and it makes rule simple.
If we take 1) senario with super column family,
I can provide a patch of my implementation.
Attachments
Attachments
Issue Links
- incorporates
-
GORA-81 Replace CassandraStore#addOrUpdateField with TypeInferringSerializer to take advantage of when the value is already of type ByteBuffer.
- Closed
- is blocked by
-
GORA-133 GoraCompiler cannot compile array type.
- Closed
-
GORA-134 ListGenericArray's hashCode causes StackOverflowError
- Closed
-
GORA-132 Uses ByteBufferSerializer for column value to support various data types rather than StringSerializer
- Closed
- is related to
-
GORA-142 Creates org.apache.gora.cassandra.serializers package in order to clean the code of store and query packages and to support additional types in future.
- Closed
- relates to
-
GORA-132 Uses ByteBufferSerializer for column value to support various data types rather than StringSerializer
- Closed