#Should Relationship fields be stored as ObjectId BSON type rather than a string?

22 messages · Page 1 of 1 (latest)

rotund dagger
#

Trying to get a better understanding as to why the relationTo field in Relationship field is stored as a string rather than a ObjectId BSON type. Mongo requires equivalent field types when doing things like $lookup or other operations using Mongo Charts or Mongo's Aggregation Pipeline,.

Is there a reason relationships are stored as strings rather than ObjectId BSON types? What are the downsides to doing this in our project by default?

https://www.mongodb.com/basics/bson

MongoDB
Explaining BSON With Examples

BSON and JSON are two distinct object notations. Learn where one is better than the other here.

magic flickerBOT
rotund dagger
#

Bumping this, hoping to get some clarity.

digital kite
#

Extra bumping this. Interested in knowing the answer too.

sinful cloud
#

There is a pluigin that will force relationship IDs to be stored as objectIDs, not sure why it isn't the default behaviour tbh

ocean glen
#

It was done this way to accommodate custom string IDs aka "bring your own IDs from a different system"

rotund dagger
#

Awesome, so if we are not "picking" our own ID's we should be okay, and would probably be better off, opting to store and reference Ids as BSON Objects rather than strings.

ocean glen
#

I would say unless you have a specific reason to use BSON, you should stay on the default for Payload

#

as mentioned above, there is a plugin that allows you to use BSON, but it will never receive the same amount of support as the default way.

rotund dagger
#

We are using mongo charts, which does not allow lookups accross diffrent types. Trying to decide if it's better to replace the way payload store the objectId or maybe add an additional field for for this purpose. IE we would prefer our objectIds to be type BSON by default, but it's unclear what the potentials risks might be when it comes to supporting Payload CMS.

ocean glen
#

Maybe @lament bay can weigh in on this.

rotund dagger
#

We are pretty sure we will never want / need to choose any db index's ourselves but would rather store custom / providerIds in the document itself

lament bay
#

@rotund dagger take a look at this plugin

rotund dagger
#

ill see if i can get this working for 2.0 and vite

sinful cloud
lament bay
#

hmm, haven't tried it. but we can give it a shot. i'd like to move it into the monorepo for better visibility

viral sky
sinful cloud
spark swan
feral nexus