data type is text but it accepting integer also why?

data type is text but it accepting integer also why?

  

i have created an API (POST method).it will accept below json as input (datatypes:name(string),address(string),age(integer)).for this below json it is working fine.

{

"name":"san",       

"address":"something",

"age":21

}

but for this bellow json value also working it is storing in table

{

"name":111222,       

"address":222222,

"age":21

}

i want throw an error for this json value how to do please help me.

Hi  Santhu,

Text data type accepts many characters. You need to create or own validation for that. At the beginning of that method you need to check if name and address are valid according with your rules.

Regards,

Marcelo

Hi,

Like Marcelo said, Text data type accept many characters. It looks to the character "1","2" and so on.

Marcelo gave one idea in a previous post that can help you: https://www.outsystems.com/forge/component/1002/restrictchars/?Unfollow=False


Hope this can help!

Best regards,

Ricardo

Marcelo Ferreira wrote:

Hi  Santhu,

Text data type accepts many characters. You need to create or own validation for that. At the beginning of that method you need to check if name and address are valid according with your rules.

Regards,

Marcelo

hi  Marcelo 

thank you for replying me ..i am getting what you are telling.but how do and what to use to get that coding done.

regards

Santhu


Hi Santhu,

In the beginning of the method use some sort of validation. this is an example but you need to decide which validation you want to use. if the validation is not met (use an if) you should return an error through an output variable

Regards,

Marcelo

Hi,


What do you want to validate? That the value just has letters or that it needs to really have the " " around it?

Would you want to give an error for this?:

{

"name":"san1",       

"address":"2222",

"age":21

}


If this result is acceptable, I think this thread will go on the same path as your previous one.


Regards,

João Rosado

João Rosado wrote:

Hi,


What do you want to validate? That the value just has letters or that it needs to really have the " " around it?

Would you want to give an error for this?:

{

"name":"san1",       

"address":"2222",

"age":21

}


If this result is acceptable, I think this thread will go on the same path as your previous one.


Regards,

João Rosado

hi  João Rosado

the attribute can accept any data but it should be within double quotes(" ") .for below json("name":111222) i need to throw an error.


{

"name":111222,       

"address":222222,

"age":21

}



Hi Santhu,

If you know in JSOn where exactly you are expecting number , you can put a validation to check only number on that particular attribute irrespective of whether it has double quotes or not and can throw an exception.


Regards,

Pramod Jain



PRAMOD JAIN wrote:

Hi Santhu,

If you know in JSOn where exactly you are expecting number , you can put a validation to check only number on that particular attribute irrespective of whether it has double quotes or not and can throw an exception.


Regards,

Pramod Jain


hi Pramod Jain

within double quotes it can be anything(ex :"11111", "%^^&^*&tyt", "ghfhjjkdjhs"),these are all allowable.

but (ex: 1111) this example is not allowable.



Like on the other post, I really see no good reason to do that.

Having any value be able to be parsed as text is a great capability on integrations that allows flexibility on the service consumers implementation. Since you are ok with accepting "1111" there is really no reason to block 1111.


I advice you from not attempting manual validation of your inputs to block that. Doing it would be very error prone, maintenance hell and add a performance impact.


Why are your requirements do focus on REST payload details rather than in the semantic and functional requirements?


Regards,

João Rosado

João Rosado wrote:

Like on the other post, I really see no good reason to do that.

Having any value be able to be parsed as text is a great capability on integrations that allows flexibility on the service consumers implementation. Since you are ok with accepting "1111" there is really no reason to block 1111.


I advice you from not attempting manual validation of your inputs to block that. Doing it would be very error prone, maintenance hell and add a performance impact.


Why are your requirements do focus on REST payload details rather than in the semantic and functional requirements?


Regards,

João Rosado

hi  João Rosado

the testing team raised it as a bug . they and development team are forcing to fix that bug ..


Solution

santhu MS wrote:

João Rosado wrote:

Like on the other post, I really see no good reason to do that.

Having any value be able to be parsed as text is a great capability on integrations that allows flexibility on the service consumers implementation. Since you are ok with accepting "1111" there is really no reason to block 1111.


I advice you from not attempting manual validation of your inputs to block that. Doing it would be very error prone, maintenance hell and add a performance impact.


Why are your requirements do focus on REST payload details rather than in the semantic and functional requirements?


Regards,

João Rosado

hi  João Rosado

the testing team raised it as a bug . they and development team are forcing to fix that bug ..


As far as I know, the JSON standard doesn't specify how the interpreter (in this case, OutSystems), have to react when a numerical type receive the value between quotes. So, it is up to the interpreter to be strict and not accept, or, as it is more common (even JAVA does that), implicitly convert the value if it is possible. 

So, it is not a bug, but a system behavior decision. 

I would recommend following @João Rosado advice and not try to force a behavior that is contrary to the platform behavior.

Cheers.

Solution

Eduardo Jauch wrote:

santhu MS wrote:

João Rosado wrote:

Like on the other post, I really see no good reason to do that.

Having any value be able to be parsed as text is a great capability on integrations that allows flexibility on the service consumers implementation. Since you are ok with accepting "1111" there is really no reason to block 1111.


I advice you from not attempting manual validation of your inputs to block that. Doing it would be very error prone, maintenance hell and add a performance impact.


Why are your requirements do focus on REST payload details rather than in the semantic and functional requirements?


Regards,

João Rosado

hi  João Rosado

the testing team raised it as a bug . they and development team are forcing to fix that bug ..


As far as I know, the JSON standard doesn't specify how the interpreter (in this case, OutSystems), have to react when a numerical type receive the value between quotes. So, it is up to the interpreter to be strict and not accept, or, as it is more common (even JAVA does that), implicitly convert the value if it is possible. 

So, it is not a bug, but a system behavior decision. 

I would recommend following @João Rosado advice and not try to force a behavior that is contrary to the platform behavior.

Cheers.

Hi Eduardo Jauch

thank you for Responding to me ..i will try to convince my manager about this issue.

thanks

santhosh MS