-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Spaces in type names lead to NumberFormatException (decimal to long) #326
Comments
Hello, the error refers col18 |
Ah yeah, I thought that was just dbptk counting from zero. :-) Will check again. |
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. |
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. |
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. |
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
the SIARD Suite writes this:
But contrary to what I thought first, it's not the obvious difference in the
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 ( |
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
The text was updated successfully, but these errors were encountered: