Api returns int for text value?


#1

Hi,

I have defined a field called Postcode and set the type text. When I enter postcode 85221 and save the collection even though this field defined as text api converts it to int inside the json. Is this expacted behaviour? How can I force api to return this value as string.

Thanks


#2

I looked into the database and it happens on save. So it’s not an output problem.

Just tested with commenting out these two lines:


Now int values are stored as strings and the api output is string, too. But I don’t understand why the checks are there. //JSON_NUMERIC_CHECK - without destroying values with leading zeros sounds important.


#3

Thanks for pointing out the correct places. Yes it sounds important but also I believe it should not convert text field values to int values? Maybe the field type check would prevent this misbehavior?


#4

No, it really shoudn’t. Some tests in a simple text field:

42e0    --> 42
42e4    --> 420000
 42     --> 42
  42    --> 42
.42     --> 0.42
4.2     --> 4.2
-42     --> -42
+42     --> 42
4 2     --> "4 2"
42-     --> "42-"
+-42    --> "+-42"

There is no number field/component to check against, but it looks like there was one in the past - https://github.com/agentejo/cockpit/blob/next/modules/Collections/bootstrap.php#L311

@artur Is there a reason for this type conversion?


#5

I created an issue on Github and pointed this discussion. https://github.com/agentejo/cockpit/issues/907


#6

Fixed in https://github.com/agentejo/cockpit/commit/4a9057541de1b557bdc92e9ea1497a3609732d16

@artur Can you explain, why the check was there? It looked important and it looked like you wrote the MongoLite class yourself in the past. I just want to understand the reason, if something else could break in the future or if other related issues come up in the future.


#7

And I have to correct myself:

See: Number field type

Using this variant and adding “42e3” as an entry leads to “42e3” in the database and the input field in the backend converts its appearance to “42000”.


#8

shouldn’t break anything, I didn’t know back then that the number casting would have such side effects