How to keep my capped array updated

Hi all in my user model i am storing the following data

     request_rec:[
        {
            type: mongoose.Schema.Types.ObjectId,
            ref: 'Trip',
        }
    ],
    request_send:[
        {
            type: mongoose.Schema.Types.ObjectId,
            ref: 'Trip',
        }
    ],

I am keeping the requests_rec, request_send arrays limited to 3 recent items by using $push $slice. So that i can show 3 items under request_send, request_received if he needs to view more then i am planning to fetch from trip model.

I feels i can easily handle addition of new request_send, request_received. But i am feeling confused regarding how i shall keep this list updated when i remove items from request_send,request_received after accepting a request. Please guide me regarding how i shall keep the request_send,request_received array filled after removing an item(ie. if i removed an item from request_received in user model then if there are more requests pending how shall copy it to request_received in usermodel).

Hi @Jose_Kj,

Have you considered using change stream yo track removal and act upon it? When a request is removed you can index the users having this request and update them by pulling it.

If you need strong consistency you can potentially use transactions to commit a delete after both delete and update are performed.

Best
Pavel

1 Like

my trip schema

const tripSchema = new mongoose.Schema(
    {
        location:{
            type: String,
            required: true,
            index: true
        },
        desc:{
            type: String,
            required: true
        },
        members:[{
            type: mongoose.Schema.Types.ObjectId,
            ref: 'User',
        }],
        pending:[{
            type: mongoose.Schema.Types.ObjectId,
            ref: 'User',
        }],
    },
    {
        timestamps: true
    });
    tripSchema.index({ admin: 1, location: 1, date: 1}, { unique: true });
    module.exports = mongoose.model('Trip', tripSchema);

ok thanks @Pavel_Duchovny, i am sorry if i was not clear. My main concern is like if there are say more than 5 requests received(pending) and we removed one from it. so what shall be the optimum criteria to select one request_received so as to copy to requests_received in user model(here in user model i am keeping copy of last 3 items).

if i removed one request , present in request_received in user model and there are more requests. then i will need to copy one from trip model to user model.

is my use model design optimum? should i remove the subset pattern request_send, request_received and directly access request_send,request_received from trip model? i will be displaying latest 3 request_send ,request_received in a single page.
thanks

Hi @Jose_Kj ,

If received and sent requests are shown as part of main user context it makes sense to keep them together as long as this array is not unboundedly growing. Since you mentioned 3 last elemnts will be stored I suppose you should have a timeDate per element and when you do the $puah with $slice sort based on the time.

Since as you mentioned only last 3 will be stored inside the user document, whenever you pull a user from the trip document you will need to check if this operation does not also required to be reflected in user document.

There are several ways to do so:

  1. Perform two operations for each removal and in both modules index the userId together with the tripid. In trips pull out the userid and in users pull out the relevant trip id.
  2. Use a change stream (or atlas trigger) and operate only on trip collection when adding removing users from ttrips. The change stream logic will implement pushing/pulling or updating the trips in user documents.
  3. Use acid transactions to update both documents and commit or rollback both together.

I recommend reading the following article which has some great tips on how not follow known anti patterns. Relationships are one with relevant consideration for you.
https://developer.mongodb.com/article/schema-design-anti-pattern-summary

Thanks
Pavel

1 Like

This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.