[Bug]-[Infinity]:A value in a cell of text datatype gets removed on running a query with a binding

[btsgh]

Is there an existing issue for this?

• [X] I have searched the existing issues

Description

When I run an update query on mysql datasource, in which I bind a value to be entered into a cell of text data type, the prior value in that cell gets removed.

Steps To Reproduce

1. Connect to a MySQL datasource. Details in Notion doc.
2. Run - SELECT * FROM users ORDER BY id LIMIT 10; Ensure that ljarrelg@disqus.com row has some value in the phoneNo cell. If not, then run - Update users set phoneNo = {{"0123"}} where email = 'ljarrelg@disqus.com'
3. Run a Select query again to see if the number has been updated for that row.
4. Now run another update query as below - Update users set phoneNo = {{0123}} where email = 'ljarrelg@disqus.com'
5. Note we get an error (SyntaxError: Octal literals are not allowed in strict mode.) but the query still runs
6. When we try to run the select query again and observe the row with email id mentioned above, we see that the update query has deleted the earlier record in the db cell.

Screenshot of the octal error that comes up in step 5

Public Sample App

No response

Version

Production

[sribalajig]

6m MySQL usage : 158

Stats

Stat	Values
Reach	158
Effort (months)	<>

[sribalajig]

@ChandanBalajiBP can you please add details about why this is happening and how we can handle the error more gracefulle.

[ChandanBalajiBP]

A number with preceding 0's(zeros) is considered an Octal number in Javascript. And javascript recommends adding o next to zero (ex: 0o123).

The above error is generated when the binding is evaluated in Appsmith.

This can also lead to conversion to an octal number from a decimal number.

var octal = parseInt('026', 8); var octal1 = parseInt('030', 8); alert(octal); //22 alert(octal1); //24

[rohan-arthur]

now there's a different problem - both the update queries run without error however:

• using {{"0123"}} stores the data as 0123
• using {{0123}} stores the data as 83, which is an octal conversion the second usecase is surprising and should be treated as a bug. For reference, on dbeaver the data gets stored as 123