Customize collection and field name

[apstanisic]

This complicates code since there is difference between column and field, table and collection. It also means that infra state must store more data. That additional data also contributes to admin panel bundle size.

Camel case pros:

• it's in line with JS style
• consistent with rest of the API
• this is abstraction over db, so it's better to not be directly tied to db schema. For example, allow user to set custom field name

Cons:

• increases complexity of the code, and cognitive load in checking if we need camel or real version

[apstanisic]

It wasn't fully. It's a useful abstraction that means that user can user same API even if their db changes. But it was definitely a mistake to do it by default, since it made writing docs much harder. Ideally, this option would be exposed to user, so they can set it how they want

[apstanisic]

Provide option if user wants to camel case columns, and that value should be user. Find all instances that you depend on camel casing and snake casing and replace them will dynamic implementation

[apstanisic]

This requires additional data in database, since currently we infer field name from database, but if we want custom values, we would have to store that info

[apstanisic]

This is also convenient if user has legacy database, and they want to create different API

[apstanisic]

Add field for collection name when creating, and always use that value. If it's empty string, generate default value (camel case). For existing table on sync, default to camel case

[apstanisic]

This complicates syncing with db a little, since some field might have a name of a column. But this is also a big plus when migrating code