objection.js
objection.js copied to clipboard
snakeCaseMappers works differently for objects and FieldExpressions
Using snakeCaseMappers
, patching an object will not map inner keys, only the first level (columns), but using a FieldExpression will map the json field references.
class TestModel extends Model {
...
static columnNameMappers = snakeCaseMappers();
...
}
// Query with array/object
TestModel
.query()
.patch({
jsonColumn: [{
innerKey: 1
}]
});
// Database output
{
json_column: '[{"innerKey": 1}]'
}
// Query with FieldExpression
TestModel
.query()
.patch({
'jsonColumn:[0][innerKey]': 1
});
// Database output
{
json_column: '[{"inner_key": 1}]'
}
EDIT: IMHO, this should work consistently across, and there could be an option for snakeCaseMappers | knexSnakeCaseMappers
, something like deep|deepKeys|innerKeys
. Obviously I would prefer it to default to false
, and I'm guessing the usual expectation is around how the normal objects now work, but the default's not a big deal for me eitherway.
Objection shouldn't touch the JSON fields at all. It's a bug that the inner keys actually do change in some case.
@koskimas agreed, the option would've been an additional feature based on the "hidden feature" ;)
I fixed this for us by:
- copying the
snakeCase
fromlib/utils/identifierMapping.js
- creating a new
snakeCaseMappers()
factory that:- uses
objection.snakeCaseMappers().parse()
for parsing - uses the copied
snakeCase
for formatting, but only until the first:
. LikemapLastPart
, but until instead of from the separator
- uses
I needed to revert the fix for this. It caused more problems than it fixed.
any news on this? (thanks for your continued great work, by the way.)
@lehni I did a proposal for this issue 😃