Make field parsing more flexible to avoid type casting errors
Is your feature request related to a problem? Please describe.
The current parsing logic appears to be very strict about the expected data types, which leads to avoidable errors. For example, attempting to parse the value 20 into a double triggers an exception because the code cannot cast an Integer to double. Similarly, when reading 86000 into a field expected to be a String, an error occurs instead of automatically converting the value. This rigid behavior makes the system fragile when dealing with real-world data, where types may vary slightly but are still compatible.
Describe the solution you'd like
I would like the parsing mechanism to be more flexible in handling type conversions. If a value is numerically compatible (e.g., an integer where a double is expected), or can be safely converted to a string, the parser should perform the conversion automatically rather than failing. This would make the system more resilient and user-friendly, reducing the need for pre-processing input data.
Describe alternatives you've considered
Additional context
Make field parsing more flexible to avoid type casting errors
Is your feature request related to a problem? Please describe.
The current parsing logic appears to be very strict about the expected data types, which leads to avoidable errors. For example, attempting to parse the value
20into adoubletriggers an exception because the code cannot cast anIntegertodouble. Similarly, when reading86000into a field expected to be aString, an error occurs instead of automatically converting the value. This rigid behavior makes the system fragile when dealing with real-world data, where types may vary slightly but are still compatible.Describe the solution you'd like
I would like the parsing mechanism to be more flexible in handling type conversions. If a value is numerically compatible (e.g., an integer where a double is expected), or can be safely converted to a string, the parser should perform the conversion automatically rather than failing. This would make the system more resilient and user-friendly, reducing the need for pre-processing input data.
Describe alternatives you've considered
Additional context