Keystone-classic: No field type for native Mongo ObjectId's?

Created on 10 Feb 2016  ·  5Comments  ·  Source: keystonejs/keystone-classic

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.

enhancement

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:

  1. We're hyper aware of which bugs exist in KeystoneJS and need to be fixed (not possible with 600 open issues, very possible with 100 open ones)
  2. We know which features the community wants most since we you can upvote them (not possible with Github issues)

Which combined mean that in the long run, KeystoneJS will be a lot better off than if we didn't do this. :+1:

All 5 comments

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:

  1. We're hyper aware of which bugs exist in KeystoneJS and need to be fixed (not possible with 600 open issues, very possible with 100 open ones)
  2. We know which features the community wants most since we you can upvote them (not possible with Github issues)

Which combined mean that in the long run, KeystoneJS will be a lot better off than if we didn't do this. :+1:

Was this page helpful?
0 / 5 - 0 ratings