luis100
commented
2 years ago Hello, the error refers col18 col18_l'='237869.25' but your report of the datatype seems to refer c19, could you check the data again to ensure your report is correct?
Open marhop opened 2 years ago
luis100
commented
2 years ago Hello, the error refers col18 col18_l'='237869.25' but your report of the datatype seems to refer c19, could you check the data again to ensure your report is correct?
marhop
commented
2 years ago Ah yeah, I thought that was just dbptk counting from zero. :-) Will check again.
luis100
commented
2 years ago This may be a re-numbering column issue (expected when loading from SiardSuite into DBPTK Desktop), fixed on #316, to be released in 2.6.1.
luis100
commented
2 years ago We do start with 0, and SIARD starts with 1. So your report might be correct. But this has not happened before. Please check if this report is correct. Also, if you could mock an example that would reproduce the issue it would help immensely.
marhop
commented
2 years ago Double-checked right now, there seems indeed to be an offset of 1 between the column numbers in the SIARD file and in the log ...
I'll try to put together a minimal example.
marhop
commented
2 years ago Well now, that was tricky.
I created a minimal example, and because I did not have the SIARD Suite at hand I just created it with DBPTK Desktop 2.6.0 - no problems at all, I could browse it perfectly fine (see attached file a.siard.zip, added the zip extension so GitHub would let me upload it).
So I compared my example file to the file created by the SIARD Suite (the one that raised the error above). Where DBPTK puts this into header/metadata.xml
<type>DECIMAL(13,2)</type>
<typeOriginal>DECIMAL(13,2)</typeOriginal>the SIARD Suite writes this:
<type>DECIMAL(13, 2)</type>
<typeOriginal>decimal</type>But contrary to what I thought first, it's not the obvious difference in the typeOriginal element that leads to problems - it's the space in (13, 2)! When I changed the entry to
<type>DECIMAL(13, 2)</type>
<typeOriginal>DECIMAL(13, 2)</typeOriginal>that is, just added a space char in the type name (see attached file b.siard.zip), browsing the SIARD file raised the NumberFormatException.
I can't judge how lenient the type name parsing should be, but since the SIARD Suite wrote those spaces at least at one point in history (or still writes them, I haven't checked), maybe you could make your parser a little more flexible to increase compatibility?
PS: Again, there was an offset between the column number in the SIARD file (c1) and the one reported in the ~/.dbvtk/log/dbvtk.log file (col0_l).
luis100
commented
2 years ago Parsing should be lenient, validation should be strict. This would then me marked as an enhancement, and maybe transferred back to the dbptk-developer as it is the part of the logic that parses SIARD into the intermediate data model.
Hi,
Description: I tried to load a SIARD 2.1 file (created with SiardFromDb 2.1.120 (SIARD Suite) from a MySQL 5.5.5-10.1.37-MariaDB-0+deb9u1 DBMS) with DBPTK Desktop 2.6.0 and got stuck when preparing for browse. In ~/.dbvtk/log/dbvtk.log the following error occured:
The relevant column definition in header/metadata.xml:
The corresponding column definition in content/schema0/table5/table5.xsd:
An example entry in content/schema0/table5/table5.xml:
Apparently dbptk tries to turn a floating point decimal into a long. Is that intentional?
Steps required to reproduce the bug:
Attach the dbptk-app.log.txt file below. → Could not find that file on my system, sorry ...
Cheers, Martin