Hi.
I was told, that the A12 Number type can hold up tp 15 digits.
I wonder how to model Numbers with longer values. What are the general recommendations?
My thoughts about this: I could write any very long value in a JSON document and the interpretation of this value is up to the processing library. So the length is only restricted by the complexity of the programming language datatype of the interpreting library (Typescript oder Java). So, if I would have a sophisticated library, I could process more than 15 digits…?
Thanks and Kind Regards,
Stefan
I’m really curious what the use case here is. Are you trying to calculate the orbital position of Pluto with an error of about +/- 1m? Or are those numbers just identifiers in disguise and should be treated as strings?
Hi @stefan-grey-canyon,
You have the option to model a Custom Field
- Add a Field
- Select Data Type = Custom
- Add the Name in the Data Type Configuration that matches the name that you have used in the code.
But now that you have your Custom Field, @andreas-fresh-mesa’s question comes into play. Custom Fields are treated like Strings in the Kernel Language, see here. It’s not possible to change the way that Custom Fields are treated by the Kernel which means that you cannot use any Validation or Computation Rules with this Field that work with the data as a number.
As a result, for any use-case that is more than saving and displaying this long number, you have to add extra custom code in addition to the definition of the custom field type.
TLDR → using a String is a sensible suggestion unless you have some validation requirements on the data beyond what is offered for a normal String Field.
@andreas-fresh-mesa Yes. Consider a field of type Number, but the interpretation of the value is unknown. For example I could write coordinates like “51.3395043,12.3737906” as “513395043123737906” and I have a very long number. In my usecase, the meaning of the value may be unknown.
The data types are only really important when you use them to apply higher-level A12 functionality to them. For example:
Computation and validation rules in the document model might depend on certain data types, often numbers, when you want to really “calculate”.
Form model dependencies require you to have their trigger fields as enumerable (enumeration, boolean confirm).
Certain UI elements (form controls) only bind to the respective field data types.
You might be able to work around some of these restrictions, e.g. by using custom conditions in validation rules, custom controls in the form engine etc.
If all of this is not a concern in your application, a string (or custom type) representation can be enough to hold the data in the documents. Then you are more or less unlimited in terms of length.
Everything else has to be done by your application-specific code that interprets these values.
