| [geomesa-users] SchemaCopyJob is failing |
|
Hello, I’ve been attempting to convert a geomesa datastore that was generated using a 1.1.0-rc.7 build to the format of 1.1.0-rc.2, using the SchemaCopyJob (https://github.com/locationtech/geomesa/tree/master/geomesa-jobs#updating-existing-data-to-the-latest-index-format).
The job is failing in org.locationtech.geomesa.features.avro.FeatureSpecificReader.readAttributes(…) – specifically on the ‘match’ statement on serializationVersion. A bit of debugging shows that the serializationVersion being passed in to readAttributes
is 0, which means that the code is not able to assign a suitable deserializer for the data in the table being converted. For reference, here’s the contents of my table metadata (generated using scant –t <tablename> in the Accumulo shell): ~METADATA_mast_sri attributes: [] aisMessageType:Long:index=false,navStatus:Integer:index=false,rateOfTurn:Double:index=false,trueHeading:Integer:index=false,cargoDescription:String:index=false,shippingAgent:String:index=false,receiverClass:String:index=false,aidType:Long:index=false,vesselType:Long:index=false,destination:String:index=false,arrivalTime:Date:index=false,destinationVerified:Long:index=false,simonVesselType:String:index=false,unenhancedObservationId:Long:index=false,streamDataTypeId:Long:index=false,dataSourceId:Long:index=false,vesselName:String:index=false,mmsi:Integer:index=true,callSign:String:index=false,flag:Long:index=false,imo:Integer:index=false,sconum:String:index=false,breadth:Float:index=false,length:Double:index=false,netTonnage:Float:index=false,grossTonnage:Float:index=false,deadweight:Float:index=false,buildYear:Long:index=false,latitude:Double:index=false,longitude:Double:index=false,observationTime:Date:index=false,semiMajor:Float:index=false,semiMinor:Float:index=false,orientation:Float:index=false,altitude:Double:index=false,trackId:Integer:index=false,imageId:Long:index=false,observationCatCode:Long:index=false,geofeasible:Integer:index=false,displacement:Float:index=false,depth:Float:index=false,height:Float:index=false,vesselPreviousName:String:index=false,yearNameChanged:Long:index=false,draft:Float:index=false,draught:Float:index=false,satTelex:String:index=false,satPhone:String:index=false,satFax:String:index=false,mobilePhone:String:index=false,previousFlag:Long:index=false,previousCallSign:String:index=false,vesselClass:String:index=false,hullNumber:Long:index=false,currentHeading:Float:index=false,currentSpeed:Double:index=false,*geom:Point:srid=4326:index=false ~METADATA_mast_sri bounds: [] 21.0593433380127:24.4429340362549:37.5012168884277:40.1512336730957 ~METADATA_mast_sri dtgfield: [] observationTime ~METADATA_mast_sri featureEncoding: [] avro ~METADATA_mast_sri schema: [] %~#s%2#r%mast_sri#cstr%0,3#gh%yyyyMMdd#d::%~#s%3,2#gh::%~#s%#id ~METADATA_mast_sri tables.idx.attr.name: [] test_tail_mast_5fsri_attr_idx ~METADATA_mast_sri tables.idx.st.name: [] test_tail_mast_5fsri_st_idx ~METADATA_mast_sri tables.queries.name: [] test_tail_mast_5fsri_queries ~METADATA_mast_sri tables.record.name: [] test_tail_mast_5fsri_records ~METADATA_mast_sri visibilities: [] Can any of the experienced geomesans tell if this particular table format is likely to cause the issue of an unrecognized serializationVersion in FeatureSpecifiedReader? Thanks! Ben From: Emilio Lahr-Vivaz [mailto:elahrvivaz@xxxxxxxx]
Hi Ben, On 07/15/2015 10:19 AM, Ben Southall wrote:
|