Modifications from $beforeUpdate and $beforeInsert not being returned in UPDATE

[avimar]

The auto-generated models include:

  $beforeUpdate() {
    this.updatedAt = new Date().toISOString();
  }

It seems to work and update the entry in the database.

But when I look at the response data from Feathers (e.g. on an update), it's returning the same updatedAt as is being submitted.
The same with other fields that I'm modifying.

In other words, feathers-objection is properly honoring beforeUpdate for the database calls, but it's not being returned to the client, the client is just getting back his own data unfixed.
I would expect that these modifications from within the model should be pushed back to the response.

Relevant Versions, all latest:
"@feathersjs/express": "^4.5.10",
"@feathersjs/feathers": "^4.5.10",
"@feathersjs/transport-commons": "^4.5.10",
"feathers-objection": "^7.0.0",
"knex": "^0.21.12",
"objection": "^2.2.3",
"pg": "^8.5.1",

[avimar]

Is it this?

feathers-objection/src/index.js

Line 779 in 03e4b8e

return newObject;

returns the new object

But then we select the appropriate columns from the original data submitted

feathers-objection/src/index.js

Line 782 in 03e4b8e

.then(this._selectFields(params, data));

[dekelev]

@avimar If you think this behavior should be changed, you can always open a PR with a short description to explain its need.

[avimar]

I would call this a bug:
create and patch return the information that's currently inside the database, honoring both objection model hooks and potentiall database triggers.

update however only returns what you pass it.

I'd expect that you can simply the results after the model has been applied the beforeUpdate but in trial debugs, newObject and the passed data are the same. I'm rather surprised. Is the model's application of beforeUpdate somehow opaque to feathers-objection wrapper?
If so, then the only solution is like create and patch - to do an update afterwards (but honoring $noSelect to opt out).

Suggestions?

[avimar]

I just started trying objection's virtual attributes - and it seems we have the same issue: those properties also don't show up in the returned object.

[dekelev]

@avimar, Please check the following issues regarding model's virtual attributes that do not return in the response:

• Cannot get Virtual Attributes to show up in any api response #117

• Virtual attribute breakage with Objection 1.6.4+ #45

[avimar]

It's not 45, I have the latest version.
I thought it would be 117, because I use discard and the like, but I'm not using those here -- with 0 after hooks I still have this issue.

What's weird is that when I do a GET, it shows the virtual attributes. It's on UPDATE that it doesn't show. I checked, and it shows on PATCH.

My guess is that these are both related -- we somehow have pre-model data: the old beforeUpdate data and similarly missing the virtual attributes.