Best way to exclude virtual properties from patches

[ericuldall]

I thought I had seem something in the docs addressing this use case but haven't been able to find it.

Here's the basic idea:

I have a service: User
That service has an uploadId that maps to the Uploads service and I want to create a virtual reference to the upload.

So User { _id, uploadId: Upload._id } when queried becomes User { _id, uploadId: Upload._id, upload: Upload {} }

The problem is if i'm working with the user object and then I send a patch, the upload property is now saved into mongo, which is not what should happen.

In feathers v4 I would use the keep hook to just define all the fields that should be allowed in the db, but now i'm wondering if there's a better way to do this with schemas and TypeBox.

So far i've tried, adding upload: Type.Readonly(Type.Ref(uploadsSchema)) but that didn't stop the record from getting inserted into mongo, so i'm not clear on what's the best way to handle this behavior.

I would never want a virtual property to get inserted back into the db, so I feel like by default there should be some easy way to ensure that.

[daffl]

You can exclude a property by returning undefined in a resolver, in your case the uploadPatchResolver:

export const uploadPatchResolver = resolve<Upload, HookContext>({
  upload: async () => undefined
})

Which will always exclude the property.

[ericuldall]

I'm curious if it's desirable in any use case to have virtual properties saved in the db. It seems a bit excessive to have to manually write a use case to include the virtual property, and then manually exclude it...either in the client or the server as you show.

I think it would be desirable to automatically exclude virtual properties during patch/put calls.

Another line of questioning... is a virtual property considered part of the schema? Should it be defined in the model? What's the best practice there?

Maybe there could be some sort of flag in the schema definition to make a property readonly?

export const itemSchema = Type.Object(
  {
    _id: ObjectIdSchema(),
    virtualProperty: Type.Virtual(Type.Ref(linkedSchema))
  },
  { $id: 'Items', additionalProperties: false }
)

I think something like that would make schemas a lot simpler to look at and make sense of vs having the logic that results in the shape of the model being sprinkled across the file. Any thoughts on this?

[ericuldall]

I guess an easy interim solution could be a hook like this too:

discard(...itemsResolver.propertyNames)

[ericuldall]

I ended up going with a custom around hook that's working well so far:

export const discardVirtualProps = (methods, ...resolvers) => {
    return async (context, next) => {
        if (methods.includes(context.method)) {
            [].concat(...resolvers.map(a => a.virtualNames)).forEach(prop => {
                delete context.data[prop];
            });
        }
        await next();
    }
}

implemented like:

 app.service(productsPath).hooks({
    around: {
      all: [
        allowApiKey,
        authenticate('jwt', 'api-key'),
        discardVirtualProps(['create', 'patch', 'put'], productsResolver),
        schemaHooks.resolveExternal(productsExternalResolver),
        schemaHooks.resolveResult(productsResolver)
      ]
    },
...

[daffl]

I like denoting it as a type but would have to look at the best way to do that with TypeBox. The helper looks good though!

[ericuldall]

Yes, I'm new to TypeBox, but it does seem to be in scope to have Types that affect the way data is handled. i.e. Type.Required, Type.Optional and other utility types. Perhaps Type.Discard fits more with the typebox syntax best, rather than something that uses feathers specific verbiage.

I think the general idea is that the field is allowed in the incoming payload, but should not be committed to the data store.