As far as I can tell, there's no nice way to store Mongo's native ObjectId type..
https://docs.mongodb.org/manual/reference/object-id/
If the object exists in the same DB the Relationship type is appropriate:
someRelatedId: { type: keystone.Field.Types.Relationship, ref: 'SomeModelName', ... }
But if the object you're referring to exists in a different DB you're forced to use a string field:
someRelatedId: { type: String, ... }
.. which works but, of course, stores the value as an arbitrary string and fails to leverage the underlying validation of the ObjectId type.
I half expected this would work:
someRelatedId: { type: keystone.mongoose.Types.ObjectId, ref: 'SomeModelName', ... }
.. but apparently types must extend the Keystone Type class.
I guess making that field type is pretty trivial, see the Text type as an example
This is very important and have many usage examples. Should be supported!
We're closing all feature requests to keep the issue tracker unpolluted. I've moved this to ProductPains, please upvote it there if you want this feature: https://productpains.com/post/keystonejs/mongo-objectid-field!
@mxstbr makes no sense to close issues just clear the tracker. Should only close when resolved or decided not be fixed/changed
It's a lot of work to maintain a large open source project, and being focussed is one of the most important aspects of managing one. We had 600 open issues, of which we closed ~400 by simply moving all feature requests to Product Pains and another ~100 were duplicates or fixed.
This means two very beneficial things:
Which combined mean that in the long run, KeystoneJS will be a lot better off than if we didn't do this. :+1:
Most helpful comment
It's a lot of work to maintain a large open source project, and being focussed is one of the most important aspects of managing one. We had 600 open issues, of which we closed ~400 by simply moving all feature requests to Product Pains and another ~100 were duplicates or fixed.
This means two very beneficial things:
Which combined mean that in the long run, KeystoneJS will be a lot better off than if we didn't do this. :+1: