gora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lewis John Mcgibbney <lewis.mcgibb...@gmail.com>
Subject [DISCUSS] Merge GORA_174 in to Trunk codebase
Date Thu, 06 Jun 2013 05:08:24 GMT
Hi,
My justification for the above is simple. We addressed GORA-174, which was
to handle ["string", "null"] unions in Avro schemas.
AFAICT, full support for Alfonso's additional functionality e.g.

- Support of ["null",type] (a.k.a. optional field).
- Support for mutitypes(3+) unions.
- Support of nested unions.
- Support of recursive optional records.
- Support of unions as value in maps and arrays.
- Serialization of topmost optional fields of the main record in "raw":
topmost ["null","type"] (optional field) will be persisted like if it was
["type"] (and non-existant column === null). This ensures data form 0.2.1
can be read.

Has now been implemented in all modules bar gora-cassandra, hence the
opening of GORA-223 [0].

I do not think it is a productive way for us to spend time forward and
back-porting patches between codebases. I've not had the best of
experiences with this in the past.

I propose to skip four failing tests in gora-cassandra e.g.
testGetRecursive, testGetDoubleRecursive, testGetNested and finally,
testGet3UnionField.

The hope is that we can regroup the effort to focus on smaller more
manageable tasks for the 0.4 development drive.

Any thoughts folks?

One last thing. Great work on this one to everyone. I contributed very
little having spent a good bit of time looking over the various commits
learnt a lot.

Lewis

[0] https://issues.apache.org/jira/browse/GORA-223









-- 
*Lewis*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message