[chirp_devel] Proposal to make use of TSQL in csv import friendlier

[Tom Hayward]

On Thu, Apr 24, 2014 at 8:15 AM,  <chirp.cordless at xoxy.net> wrote:
> Tom,
>
> Thanks for the agreement on the direction, and I'll be happy to
> implement any way that makes sense.
>
> The import_logic function _import_tone() isn't setting rtone to 88.5,
> it's setting it it to ctone, which csv import set to 88.5 because there
> isn't any such column in the csv, and then because the CSV pseudo
> radio is defined as having both rtone and ctone:

Let me try to understand this a little more thoroughly. Correct me if
any of the following is not true.
- The logic you are suggesting already exists in import logic
- Import logic doesn't help in your case because you have an out-of-spec CSV

Where'd you get a CSV without all the Chirp columns? (just curious)

We already have lots of support for interpreting various differences
in CSV. I don't see how supporting more oddities (like a missing
column) is a problem--go for it!

I wonder if there is a better way to handle this. Like, if a CSV file
is detected as to not be the standard format, maybe we pipe it through
import logic so we don't have to essentially duplicate those rules in
the CSV driver.

Tom