When CodecRegistry needs to create a codec on the fly for an UDT or Tuple received from a ResultSet, the CodecRegistry needs to be manually propagated to these UDTs and Tuples, including nested ones. Currently, only the first level is correctly handled; nested levels will have their CodecRegistry instances set to null, thus throwing NPEs.
Simple test to verify the bug:
Background:
Our current test suite failed to detect it because all tests first insert an UDTValue, and then retrieve it; when creating an UDTValue from the Cluster metadata, the CodecRegistry is correctly set; then the codec is cached, and that codec is returned, and everything is fine.
The problem only arises when the CodecRegistry creates the UDTCodec out of a UserType returned in a ResultSet; in this case, the CodecRegistry will create on the fly a codec for a UserType that does not hold a reference to a CodecRegistry.
Environment
None
Pull Requests
None
Activity
Show:
Jeremiah Jordan
July 31, 2015 at 4:28 PM
This branch fixes the problems I was having.
Jeremiah Jordan
July 29, 2015 at 6:56 PM
You have the same problem for a tuple nested in a UDT.
When CodecRegistry needs to create a codec on the fly for an UDT or Tuple received from a ResultSet, the CodecRegistry needs to be manually propagated to these UDTs and Tuples, including nested ones. Currently, only the first level is correctly handled; nested levels will have their CodecRegistry instances set to null, thus throwing NPEs.
Simple test to verify the bug:
Background:
Our current test suite failed to detect it because all tests first insert an UDTValue, and then retrieve it; when creating an UDTValue from the Cluster metadata, the CodecRegistry is correctly set; then the codec is cached, and that codec is returned, and everything is fine.
The problem only arises when the CodecRegistry creates the UDTCodec out of a UserType returned in a ResultSet; in this case, the CodecRegistry will create on the fly a codec for a UserType that does not hold a reference to a CodecRegistry.