Conversation
There was a problem hiding this comment.
Do we need to overload this method? I don't think we need the AvroAdaptorProxyFieldLevelVisibilityHandler either. The only difference between AvroAdaptorProxyFieldLevelVisibilityHandler and AdaptorProxyFieldLevelVisibilityHandler is the type of the data adapter. However, I don't think we need to be specific about the adapter type in the Avro visibility handler because the AvroFeatureDataAdapter is a FeatureDataAdapter. In short, I think we can reuse the AdaptorProxyFieldLevelVisibilityHandler in this method, but if we do that, the method remains unchanged from the base implementation, so I don't think we need to overload this method at all. Hopefully that makes sense. If not, let me know.
Also, this is not directed specifically at you as the naming convention has been in place for some time now, but bonus points to you if you add a commit which renames all instances of "adaptor" to "adapter" throughout the project, d'oh! :)
There was a problem hiding this comment.
makes sense, I created this before extending FeatureDataAdapter. I will remove the override and the unnecessary avro handler class.
50d2038 to
23343ea
Compare
…impleFeature as a single object. Included is the avro schema to create the generated types from chris bennights Import/Export project, these are necessary for serializing/deserializing the SimpleFeature
|
Looks good to me. |
Addition of AvroFeatureAdapter
This new adapter is intented to serialize all the attributes of a SimpleFeature as a single object. This is meant as an optimization when visibility is the same for all attributes of the feature.
Included is the avro schema to create the generated classes from chris bennights Import/Export project, these are necessary for avro serializing/deserializing the SimpleFeature.