We’re using MongoDB Atlas as a cloud service for our database. However as you all know, MapReduce isn’t supported for anything below M10 clusters.
We followed the “Enrich your models” guide in the documentation, and generated schemas. Our data is not showing successfully on Forest Admin. However, references/relationships are not working, no matter what we do.
A simple example:
customer hasMany subscriptions
But under a given customer, the list of subscriptions refuse to show.
Further information:
It feels like the reference is somewhat successfully being built, as there is an option to “Create subscription” where no subscriptions are shown for a customer. When we fill out the form, the subscription is successfully created too. But the extended views (list of subscriptions for a customer, and the customer details for a given subscription) just refuses to show up.
Any help will be duly appreciated! 
Hi @Solias99,
Thank you for reaching out and sharing your issue.
I’m not quite sure to understand, appart from your related data, is the rest of your collection accessible and displaying the correct data?
Also to assist you I might need to take a look at your model definition. Could you share it?
Sure thing.
The collections individually, (Customers and Subscriptions) are accessible and display everything right. Only the references don’t work, in the sense that when I navigate to a customer’s subscriptions, it’s an empty list, even though in the below screenshot you can see that the customer has a bunch of subscriptions.
Customer Schema
const schema = mongoose.Schema({
subscriptions: [{ type: mongoose.Schema.Types.ObjectId, ref: 'subscriptions'}]
})
There is no belongsTo in the relationship.
@Solias99, I haven’t been able to reproduce the issue.
As I can understand from your screenshot, your Customers model does have an array of subscriptions as one of its field right? (as stated in our documentation, it’s mandatory to have your relationship displayed in the related data section)
Yes, the screenshot I posted above is one document in my Customers’ collection. You can see that an array of subscription IDs is present.
Have you tried reproducing the issue using Atlas? Specifically, without mapReduce, so you’ll have to write all the models/schemas yourself.
Is there some way we can get in contact off this platform? I am confident it’s a 5-minute fix, but it could also potentially be a breaking bug on your end.
Edit: I’ve changed the way the a primary key is assigned to the Customers table (Instead of Mongo’s default id, it’s a 10 digit number coming from somewhere else. Could that be a potential reason for this whole setup breaking?
Hello @Solias99,
Your _id should be ObjectID, it’s very recommended. It offers features and is very well managed by Mongo (and Forest). https://docs.mongodb.com/manual/reference/method/ObjectId/
Further of that, let’s consider your “customers” and “subscriptions” collections.
-The customer schema is good (but where are the other fields, they should be together here)
-The data extract you showed in your last screenshot indicates in a correct way a customer document having many subscriptions.
Please try to generate your schema locally (with a local Mongo) before deploying it, if it doesn’t work manually.
Regards
Hey,
Guess we’ll change it to the default ObjectID then, and see if it fixes stuff.
Regarding your additional points,
-I omitted the rest of the fields for brevity,
-Yup. That’s why I’m confused as to why the Subscriptions woulddn’t be showing up for that customer. Not using ObjectID for customer’s _id shouldn’t necessarily break that, right?
yes, since it’s customers’id that was changed, it should not mess with customers.subscriptions -> subscriptions.
If your problem persists, can you have a try with a local mongo?
Like that relationship will be generated (and if it’s not generated with a local mongo, it means something weird is in the data, and we will look at it together).
May I know what you mean by local mongo? Right now we have a full-fledged back-end with an endpoint to fetch all subscriptions for a customer and it works fine. (Still connected to Atlas)
You want me to connect to localhost:27017 and test right?
Yes, if you can do that, just for debugging purpose.
Like that you will have your schema generated with relationship using the mapReduce provided by a local database.
Mongo can be shipped locally quickly in a docker container.
Alright I’ll look into it.
Meanwhile is it possible that you can try reproducing this error on your side as well? (without mapReduce)
Problem statement:
- Don’t use ObjectIds for primary key, use a number instead.
EDIT: By the way this above problem statement raises another problem I wanted to bring up: I can’t create a customer through ForestAdmin at all! It says “_id” is required even though _id is a locked/disabled field when creating a document.
EDIT2: This is somewhat intentional however. We don’t ever want to be create customers through here. It happens in some other microservice where we get a uniqueID. Just wondering if this problem is correlated with the customers.subscriptions->subscriptions problem
Oh yes, hacking default _id in Mongo is really really not recommended.
2 Likes
Looks like we’ll have to change our strategy and stick to default _id then. Will try that later in the evening, see if the references are working and then get back to you. (Will also try local mongo once)
1 Like
Hey @Solias99 
Did you get more success trying to stick to the default Mongo _id?
1 Like
Hey @anon34731316,
Yes, we got everything to work with default _id.
Maybe I can raise some sort of PR for the documentation regarding working without them? It’s not all that uncommon for people to replace _id, I’ve done it before for various purposes, including (but not limited to) replacing them in favour of IDs being generated in another application.
2 Likes
