Open avimar opened 4 years ago
@avimar Thanks, I'll consider adding support for ObjectionJS context
method.
A model is usually not used to call other services or trigger events and I wouldn't use the app
instance in a model in my app since it prevents the model from being shared as relation for model in another app.
For separation of concepts, interaction between services and business logic should be applied in the service's hooks file.
The hooks methods in a model file are usually used to set "auto-generated" columns.
You can also use the $modify query operator to apply shared common query snippets.
👍 for adding support for the .context()
method! :)
One possible use-case on our end would be to pass request information to objection hooks like $beforeInsert
Objection has it's own hooks. Feathers is already passing in params which can be given to objection's
context()
function. It has the authentication information, when available.https://github.com/feathersjs-ecosystem/feathers-objection/blob/master/src/index.js#L276 Would become:
const q = this._createQuery(params).context(params).skipUndefined();
and is accessible in queryContext from many hooksWhat about the full
app
for accessing other things? I know this is probably crazy, but I'm experimenting with different ways of writing my logic, and doing some of it at the model seems to make some sense.I'm not familiar enough with classes - I'm pretty sure we're passing in app, that's how we can use the config to connect to the DB, but how can I access it within the class again later? e.g. to call other services or trigger events.
Thanks!