CSV import broken

[Miika Turkia]

On Sun, Mar 15, 2015 at 1:29 AM, Dirk Hohndel <dirk at hohndel.org> wrote:

> On Sat, Mar 14, 2015 at 03:18:37PM -0700, Dirk Hohndel wrote:
> > On Sat, Mar 14, 2015 at 08:51:50PM +0200, Miika Turkia wrote:
> > > It seems that patch 0ed4356fc28b9cf9474bbbfcdeb9bc49ff83b9ec broke the
> CSV
> > > import. Currently I don't see how to fix it, so reporting here.
> >
> > Err, oops. I'll look into that.
>
> The reason for that is that all the XSLT files set Version to 2 which
> aborts the parse until the warning about this potentially taking a very
> long time has been shown - but the code path for import never does that
> and therefore the import keeps failing.
>

Makes sense.


> The actual fix is to have the XSLT files changed to provide Version 3 XML
> files. For now it's easy enough to hack around so that it at least works.
>

I do not (at least initially) agree on producing version 3 from XSLT. This
is because we cannot produce proper v3 from the CSV as the dive site
lookups are not going to occur, and the IDs might be incompatible (I
believe, we could use an extension that produces sha sums, so the IDs would
probably be OK). I am not sure how big an issue this is, but it might make
sense, to produce v2 and do the proper conversion afterwards.

Also the parsing of CSV files would probably be even more complex than it
currently is. But I might still be able to do it in somewhat sensible way,
even though I have not tested my ideas, at least not yet.


> I just pushed such a patch.
>

Thanks, now I can try to track down the other issues reported with CSV
import (depths).

miika
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20150315/5690c958/attachment-0001.html>