Implement ingest command that leverages the AvroDataFileReader

Implement ingest command that leverages the AvroDataFileReader

Original JIRA Issue: https://geomesa.atlassian.net/browse/GEOMESA-2868

Key: GEOMESA-2868
Type: Improvement
Priority: Major
Status: To Do
Resolution: Unresolved
Reporter: James Hughes
Created: Wed, 3 Jun 2020 14:37:53 -0400
Updated: Wed, 30 Sep 2020 13:19:20 -0400

Comments:

557058:da7f6dfa-f0a1-468b-aec5-2cb61273feb5 (Mon, 27 Jul 2020 16:53:30 -0400):

Do we still want this? Or is type inference good enough, now that we've fixed our avro schema?

557058:da7f6dfa-f0a1-468b-aec5-2cb61273feb5 (Thu, 3 Sep 2020 16:25:59 -0400):

James Hughes ok if i close this?

557058:48912df4-0004-4f90-9915-db26684ec006 (Thu, 3 Sep 2020 17:13:07 -0400):

I’m still of the opinion that a GeoAvro file is worth an SFT+SFCollection and it’d be sensible to ingest it directly (sans converter). Thoughts?

557058:da7f6dfa-f0a1-468b-aec5-2cb61273feb5 (Thu, 3 Sep 2020 17:58:04 -0400):

I think we're likely to get into more complicated scenarios, similar to what we're thinking about in nifi, where we start layering options on top of the avro ingest command... when those would all be covered by using a converter. and the auto-detect should work (now) for a straight up unchanged ingest, just pass --force. so i'd say don't have a separate command.

557058:da7f6dfa-f0a1-468b-aec5-2cb61273feb5 (Thu, 3 Sep 2020 17:59:59 -0400):

this issue only arose b/c the geoavro wasn't actually valid avro... speaks to the point about not having separate ingest pathways IMO.

The issue names AvroDataFileReader and an ingest command but provides no file or test path; start by locating the existing ingest command entry point and its use of the reader. Resolve the comment-thread question about whether a separate command is still wanted before defining what done means.