[BUG] Generated code handling records with more than 30 fields fails silently. #285
Comments
|
Or... it may be the fact the omitted field is an "int64" field ? How is that handled in the generated code ? |
|
Hi @RoarGronmo Will check it today |
|
@RoarGronmo I have generated your 2 files and everything is OK with Ord object. noteHash field is generated. Could you please explain what is problem here? I see only problem with TextTp field. This integer has generated like class. |
|
Thanx for reaching back to me, Have used some time to really dive into the code here and the json's which is read.
when my record is like this: , after reworking my code to test that part, I got this error message (sorry that I can't pinpoint to the actual records, the reason is not the record above): Is there a way to guarantee that even if
|
|
And yes the TexTp field is failing, but that is a missing include, actually had a plan to report that too, but that one I got an intermediate manual solution for => include the missing library manually. |
|
Here's the point where code says it crashher (from And here's a typical json which the and where it fails. |
|
Hi again @RoarGronmo TexTp is failing because of our bug :) We don't recognize it like Enum. Actually, it's enum with integer values. To define swagger type we using next map: If we want to recognize int128 as double we should just add it here. |
|
@RoarGronmo int64 is parsing in integer. It can't be larger. Dart does not have 'long' type or something like this. We can parse it into double if it will help. |
|
Yes, that would be better, but the problem is when you parse it like that you might be in a missing information situation. At this particular case we have 64bit int hash, where I need the bits to be "in place" even if it is double... can you guarantee that when converting from int64 to double, and back ? |
|
@RoarGronmo can you please provide example, what should we generate in this case? That will really help me |
|
The really best would I setting (or annotation somewhat) to parse it to byte array or int array, when you may surpass int64 or int128 boundaries, or even to a string. |
|
At the moment would it be best to convert it to a String, then you gurantee that you keep the information. |
|
With a setting |
|
My manual approach now is actually to read it as a |
|
So a setting/annotation so I can convert from and two different interchangeable types would have been very nice. |
|
@RoarGronmo actually your number is bigger than 15479906050049593000 max value of int64 is is it possible to return String from backend? |
|
We can parse it in double. I think it will help. |
|
@RoarGronmo I have fixed your swagger in PR above. I generate int64 values to double fields. Is it fine? Also I've fixed issue with enum. You not need any imports to compile your file. Please check v2.2.8 |
|
Thanx a lot, I'll give it a try, early tomorrow, or later this evening. |
|
Observing that somehow the swagger (Another approach is defining it as a dart The issue with the missing include seems to be fixed ! |
|
Hi @RoarGronmo Oh no :D Everything worked on my side) Will try to parse int64 to num. Give me few minutes |
|
@RoarGronmo Please check 2.2.9 version )) |
|
Ill do soon !! BTW: We have had an intense internally discussion with our backend team, and found a strange issue (not related to you directly but more on how Flutter / Chrome handles 64bit data sets).
This may explain the cause where int64 values got overflow, and even Flutter DevTool does this strange thing:
And here's same call in PostMan:
So, you see in this particular situation the three latest digits are omitted/changed/added. I am not sure where this come from (no links at the moment, the guy who gave me this have gone home for dinner...) And yes, maybe we managed to persuade the backend team to use string instead ;) |
|
Here's the reference to why 000 may be added to int64: |
|
swagger
|
|
Ahh yes. I fixed int64 in request parameters. Still need to fix model parameters |
|
@RoarGronmo I've fixed it. Please check 2.2.10 version. Please let me know if everything OK. |
|
...at least... it is translated as a num, and then it is up tp Dart to decide if 64 bits are preserved or not...
happy result:
|
|
But anyhow, I can't blame you for the result here then, the trouble is how Dart is handling num, mostly because they translate it to double and back, and there we have the information preservation situation loss... and maybe a BIG issue for Dart ?
As I said prior here, you could have a kind of setting / annotation where you could convert int64 to string, and all the digits got preserved. I refer to the post here discussing different number representations in Dart: And thank you for your big effort to make this work. We just need to persuade our back-end team to convert hashes to strings, as you clearly said before. Happy Holiday ! |
|
Hi @RoarGronmo |
|
PS: The above was from web version of the app , this below is from native test: At least here it is read correctly, so there might be some hope... (53 bit problem in web ?). |
Describe the bug
After adding some fields to a (working) record, the generated code fails out of the blue. It fails silently with no error casting or reason. Code generation seems ok (no significant warnings or errors). I have pinpointed the failing reason in the swagger file to be when a record contains more than 30 fields, then the generated code will not return anything from that record.
To Reproduce
Working swagger code
Failing swagger code:
The only difference between those two is in line 1241 to 1246 in the non-working one:
where that section is omitted in the working swagger file, and is the 31'st field in that
Ordrecord.Expected behavior
Read the data as the working one
Library version used:
pubspec.yaml:
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: