CSV import

[Anton Lundin]

On 08 January, 2015 - Miika Turkia wrote:

> On Wed, Jan 7, 2015 at 5:25 PM, Dirk Hohndel <dirk at hohndel.org> wrote:
> 
> > On Wed, Jan 07, 2015 at 03:01:31PM +0200, Willem Ferguson wrote:
> > > I have a Subsurface xml file log (7 dives) that I export to CSV, checking
> > > the option "CSV dive details". Two issues:
> > >
> > > 1) The Subsurface exported CSV data are comma-delimited, yet the
> > Subsurface
> > > import panel has a default of tab-delimited. Given the column headings
> > > provided by the CSV export file, it should be rudimentary to test for the
> > > delimiter used and set the preference in the import panel accordingly.
> >
> > Funny, that's an idea that I had last night. Do trivial, minimal parsing
> > and at least auto-detect our own format :-)
> >
> > > 2) This brings up a second issue. The Subsurface export file provides
> > > headings upon re-import into Subsurface and the  CSV import table shows
> > the
> > > imported heading in row # 2. So, it's not necessary to supply the
> > headings
> > > because they were provided by the import file. But now, what should one
> > do
> > > with the empty first row of the table? See attached screenshot 1.
> >
> > That's where the headings need to be dropped. What we need to do is what I
> > said above - it needs to be pre-populated.
> >
> 
> Some other CSV exports have headers as well. I suggest that we display the
> header line, but allow user to mark it as a header -> grayed out during the
> configuration and to be dropped on the import. It is useful to see the
> actual column names when configuring the import (a lot easier to match the
> correct tags).
> 


Be able to skip X lines in the beginning would be nice.


> > > in the import table: impossible to parse for import.
> >
> > That simply is an invalid format.
> >
> 
> IIRC the current XSLT attempts to import multi-line notes properly if they
> are quoted with "". And we do export multiline notes on CSV export.. So we
> need to either support them reasonably well or discard them on our own
> export.
> 
> >
> > > In hand-prepared CSV imports, the program handled the information much,
> > much
> > > better.
> >
> > Yes - we have no concept of importing such dive/deco plans right now.
> > Sure, something we could add, but that's a whole new level of interesting
> > complexity.
> >
> 
> The multi-line notes are really complex to parse with XSLT and I am sure
> there are a lot of errors there. And they are really against the concept of
> CSV where each line should be one dive. I am totally ready to discard the
> support for multi-line notes altogether and require one dive to be one
> line. And on our own export grab only the first line of the notes. Would
> make everything a lot simpler on the parsing side. And way less bugs in the
> code.
> 

One thing we might do is to skip or encode newlines in the export.
Eg %10, 
 or something, and de-code such on import.


//Anton


-- 
Anton Lundin	+46702-161604