Column names from CSV are being wrongly considered to define the "key" not respecting the sensitive-case

[fellipetav]

Describe the bug
Consider you have some data to be imported using a CSV file, and you have column names such as "myURL". After importing, Rowy is creating the respective column name as "myURL" but the key is created as "myUrl". As a result, the field in Firestore is consequently wrong.

To Reproduce
Steps to reproduce the behavior:

1. Create a Table in Rowy with two columns and 1 or 2 rows (does not matter if you have custom or random ID).
2. Define the name of a column as "myURL" and ther other as "mySecondUrl". For both, keep the key string exactly as it is at the name, i.e., "myURL" and "mySecondUrl" (note the last "r" and "l" are lower case).
3. Fill some data (short text) for your 1 or 2 rows.
4. Export all columns to a CSV file.
5. Create another Table with a different name than the first one.
6. Use that CSV file as input to import the data to that second Table (how to). Be careful and observe that the name of all columns are kept as it is, i.e., "myURL" and "mySecondUrl".
7. Note that after the importing the key for the column "myURL" is "myUrl".

Expected behavior
It was expected to Rowy keep the key for the column "myURL" equal to "myURL" instead of "myUrl".

Screenshots
Not applicable.

Rowy Run version
Rowy v3.0.0

Desktop (please complete the following information):

• OS: [e.g. iOS]: Windows 11
• Browser [e.g. chrome, safari]: Chrome
• Version [e.g. 22]: Version 116.0.5845.188 (Official Build) (64-bit)

Smartphone (please complete the following information):
Not applicable.

Additional context
Not applicable.

[nithinrdy]

Hey @harinij, mind if I take this up?

The field name conversion takes place here (i.e. from myURL to myUrl, for example).

However, I don't think removing the conversion (so the field key stays the same as the actual column name) is the right solution. The fact that the the field key is customizable by the user (when initially creating the column manually), means that no standard conversion (camelCase, or otherwise) -- or even no conversion at all -- is guaranteed to work in every case.

• One option is to remove the user's ability to manually change the field key when creating columns -- so the key would always be the column name in camelCase form. Then we can always obtain the field key using the same conversion.
• Another option is to allow the user to manually enter/change the field keys at the time of importing a CSV, as part of the import CSV wizard.

The latter option is obviously a lot more flexible and gives the users greater control. Please do let me know if I missed something.

[harinij]

@fellipetav this is fixed in our recent release by @nithinrdy 🎉

[fellipetav]

• Another option is to allow the user to manually enter/change the field keys at the time of importing a CSV, as part of the import CSV wizard.

@nithinrdy , this option is great!