Take advantage of Joi's `meta` ability to specify `columnName` for a property

[William Woodruff]

This feature will allow Schwifty to retro-fit onto an existing database with strange or ugly column names, preserving your right to have sensible prop names that're easy on the eyes.

When writing a joiSchema, be able to specify the database's columnName that maps to this property like so:

{
    fieldName: Joi.string().meta({
        columnName: 'field_name'
    })
}

[devin ivy]

@mattboutet is this something you've ever wished for since schwifty v1 came out?

[Matt Boutet]

Nope, but to be fair, I've not yet been saddled with an old/janky database.

[devin ivy]

I'll leave this as a request for now. My guess is that when schwifty-migrations comes through we'll want to be able to set options like this.

[William Woodruff]

Adding to this meta addition, I was thinking it would be great to support specifying other things in the meta for a model's property. For example: specify db varchar length (defaults to 255) in the meta so you don't have to dig into the knex migration file every time

[Jason S.]

This was an initial turn-off as I was investigating whether I wanted to use Schwifty. But in case anyone stumbles upon this, it's possible to use camelCase properties in JavaScript while keeping snake_case column names in your database.

These two methods involve creating your own instance of Knex and passing that to Schwifty when registering the plugin. The conversion happens at the Knex-level, so in most cases these options have the benefit of allowing you to use the camelCase version when using the Query Builder methods.

• knexSnakeCaseMappers - Handles camelCase to snake_case conversion automatically. You will still have to follow some conventions, since the conversion is automatic.
• knexIdentifierMapping - This is an explicit mapping that you provide. The link includes an example of how you could add a column property to your models in order to keep that information with the model.

I personally use knexSnakeCaseMappers. (I don't use Knex's migration features, but if you do, it seems there is an issue related to migrations and this option - Vincit/objection.js#1144.)

Alternatively you can set a columnNameMappers static property on your model(s). Objection exports a function that you can set on this property to get the commonly desired camelCase ↔︎ snake_case behavior. Because this happens in Objection, you would still need to use snake_case column names whenever you use Query Builder methods. This is a good choice if you just want to convert between database column name ↔︎ JavaScript property name ↔︎ JSON (stringified) property name.

There are pros and cons to each, so I encourage reading the relevant Knex and Objection documentation.

[devin ivy]

I am closing this, mostly because I think it has become a bit old/stale. We can reopen if folks become interested again or want to spec out a specific feature proposal. I personally think this would make for a great schwifty/objection plugin or even just a function to work with static columnNameMappers() similarly to objection's snakeCaseMappers().