Indexes are not automatically recreated if collection is dropped [DATAMONGO-345]

[spring-projects-issues]

Doug Donohoe opened DATAMONGO-345 and commented

Scenario:

template.dropCollection()
template.insert(obj)

Issue: Indexes are not recreated when the insert happens.

Cause: The MongoPersistentEntityIndexCreator.checkForIndexes call caches the fact it looked at the entity class in classesSeen. This is called first for the dropCollection method. After which, when I go to insert an object, since classesSeen isn't updated, it doesn't know it should recreate the indexes.

Conceptual solution is to notify the MongoPersistentEntityIndexCreator when collections are dropped.

---

Affects: 1.0 M4

Issue Links:

• DATAMONGO-660 Index not automatically created
  ("is duplicated by")
• DATAMONGO-986 Recreate Index when collection gets dropped
  ("is duplicated by")
• DATAMONGO-1632 Dropped collections do not trigger index creation
  ("is duplicated by")

2 votes, 3 watchers

[spring-projects-issues]

Oliver Drotbohm commented

It seems the behavior you'd like to see is better reflected with MongoOperations.remove(…) piping in an empty query. Removing a collection in MongoDB actually has the semantics of dropping it entirely so I don't see why one would expect the index to be recreated on recreation of the collection. To generally cicumvent the "missing index" issue we'd have to make sure the indexes exist for each and every storage operation because it might transparently create a collection which would add significant overhead to them. So wouldn't MongoOperations.remove(…) be a better fit if you want to empty the collection and keep the indexes in place?

[spring-projects-issues]

Doug Donohoe commented

I did end up doing a remove instead of drop, but I still think this is a bug. Consider this.

Normally, if a collection doesn't exist and I do an insert, it is auto-created with the indexes. That is my favorite thing about Mongo.

However, if I drop a collection, and go to create a new collection, it is auto-created but without indexes. That seems odd to me. It is effectively the same case. I'm creating it from scratch, but this case results in no indexes.

My use case is that the collection I'm creating is to be used for searching. If I want to rebuild the index, I want to re-do it from scratch, to ensure all indexes that may have changed are properly created. Seems logical to me to drop first.

[spring-projects-issues]

Doug Donohoe commented

By the way, I don't agree with this statement:

To generally cicumvent the "missing index" issue we'd have to make sure the indexes exist for each and every storage operation because it might transparently create a collection which would add significant overhead to them.

I'm not suggesting you stop caching the index check - I think it is perfectly correct to avoid re-doing that work on every single operation. However, if you drop a collection, you should reset any cached data relating to that collection, including whether or not you checked for indexes

[spring-projects-issues]

Oliver Drotbohm commented

Normally, if a collection doesn't exist and I do an insert, it is auto-created with the indexes. That is my favorite thing about Mongo.

That's not something you get with Mongo but with SD Mongo. Beyond that, the index is not created if you persist the entity for the very first time but rather when the entity is added to the MappingContext. So index creation is not directly related to any CRUD operation but the mapping information.

I am not explaining this because I am against the idea in general, just to explain why it currently works the way it works. So we might extend the indexing capabilities to listen to more events (persistence operation related ones) and especially wipe out the "classes seen" on collection removal.

Scheduling for the first 1.1 milestone

[spring-projects-issues]

Mark Paluch commented

We decided to deprecate auto-index creation features as that functionality causes more trouble than good so we're not going to follow up with this request