0

I get an application that displays a list of item. A list is a document An item is a document that has a listId Each item may have an itemImage (using collectionFs)

On the page i have some subscriptions. Some of them are 2 counters of the current list based on the total of item in db (which is not the same than total of item displayed) and the total of item that has some special status.

When the user remove all those items it sends a Meteor.call('remove', listId) to the server. On server the methods called doesn't remove items directly but it loops over the list using a 

items.find({listId: listId}).forEach()

And inside the foreach I remove documents from itemImage Collections

If there is more than 1000 items (dev server) then it blocks the interface because : the counters displayed are decremented in real time (nearly). When the server has finished then all pending subscriptions are run. So during this pending time the user is blocked.

I tryed to stop subscription on counters, but i don't succeed.

Maybe my application is badly thought. What is the solution ? modify the mongoDb (but in which way ?) or managing in another way the subscriptions ?

I still want to get the counters reactive, because it's a better feeling for user when there is new item saved in mongo. But when i do remove, in fact, it's almost useless. Thanks

rzymek
  • 9,064
  • 2
  • 45
  • 59
Rebolon
  • 1,257
  • 11
  • 29
  • Could you put the `item` id on each `itemImage` document, so you can remove the itemImages with a single query? – sbking Dec 18 '13 at 21:12
  • my itemImage already has itemId, inside the forEach i use itemId to remove the itemImage but if i can remove image with a global query on listId, i cannot do it wih itemImage. – Rebolon Dec 19 '13 at 08:07

2 Answers2

1

Yes, this is a real bottleneck. You definitely want to stop the subscription during large db changes. I describe one solution to that in this answer: Meteor's subscription and sync are slow

The idea is just to put a guard on the templates that use the collection being changed, so that you can break the reactivity while updating the DB.

Community
  • 1
  • 1
Christian Fritz
  • 20,641
  • 3
  • 42
  • 71
  • first i'll try to add listId in metadata of itemImage to test global remove query. If it doesn't work i'll have a look at this solution, thanks, i'll up the post when a solution ha been found – Rebolon Dec 19 '13 at 08:08
0

Ok, so i consider that it's a mis-conception of the application.

I have to modify the app to prefer direct removing with Collection.remove({myQuery}) than a loop over a Collection using a cursor that will help me to do remove based on _id.

Doing a loop is blocking if you don't provide a callback. Maybe you might be able to improve performance using a callback (even if it does nothing).

But this solution doesn't answer me to : why i cannot stop a subscription when there is a huge modification on database (lot of remove).

Rebolon
  • 1,257
  • 11
  • 29