Unexpected object caching

[drbarto]

For testing purpose, I regularly want to reset the database content with mongorestore (parse-server is shut down while running that command). After the reset I run some code which creates a new class. Then, when I repeat the process -- reset the db, run the code again -- something weird happens: Parse seems to remember that class's instances from the previous run and recreates them. So with every run, I get more instances.

Again in short:

1. reset mongodb
2. create new class, add instance A
3. reset mongodb again
4. create new class, add instance B
5. now Parse contains instances A and B!

Can this be explained, or is it a bug?

[flovilmart]

That is highly unlikely as we don't store anything on Parse-server itself. That has to be related to your restoration process.

[drbarto]

Any hint how I could evaluate whether it's related to the mongodb restoration?

The "ghost objects" for sure don't come from the backup data itself. I created the dump once and did not touch it afterwards; by looking at the objects' createdAt dates I can see that they have been created after the dump was exported.

Btw -- I even could reproduce this with parse-dashboard: after the db reset (step 3 in my above list) I tried to manually add a class of the same name from inside the dashboard (without creating any instances); as soon as the class appeared in the data browser, the old instances popped up again.

[drbarto]

I tried to reproduce the issue with a fresh system and came to the same result. Here are the required steps:

1. start a new, empty mongodb instance
2. start a new parse-server pointing to the mongodb instance
3. create a dump of the initialized db (mongodump -h localhost:27017 -d dev -o mongoexportmongodump -h localhost:27017 -d dev -o mongoexport)
4. start parse-dashboard for the new server
5. create a new class, e.g. Data, add a new column (e.g. name), and ceate a few instances (e.g. with names "stuff" and "more stuff")
6. reset the database to its initial state (mongorestore --drop --db dev --dir mongoexport)
7. open dashboard again, as expected there is no custom class
8. again create a custom class and add a column, with the same names as in (5)
9. the previously created instances reappear inside the dashboard

In my test environment this process reproducibly results in the described issue. Can someone confirm?

[steven-supersolid]

I think this is happening because of your usage of drop:

Before restoring the collections from the dumped backup, drops the collections from the target database. --drop does not drop collections that are not in the backup.

So in your backup there documents for _Schema but no documents for the Data collection. When you restore, the _Schema will be dropped and recreated. Data will be unaffected. This will result in the dashboard not knowing about Data until you recreate it.

If you took your backup after creating the Data class but not adding data then you would get the same result without having to recreate the schema.

You can also verify by repeating your steps up to and including 6, then enter the mongo shell:
db.Data.count() should verify the Data documents were not removed.
db.Data.drop() will actually remove the documents and the collection

[drbarto]

Great, thanks for your help with this! I'll change my test process to just copy a backup mongo data dir over instead of using mongorestore. This makes the process less easy to automate because starting/stopping mongodb from script is not as straightforeward, but at least I no longer have those objects reappearing.