Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
spring-projects-issues opened this issue Dec 8, 2011 · 5 comments

Comments

@spring-projects-issues
Copy link

@spring-projects-issues spring-projects-issues commented Dec 8, 2011

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
Copy link
Author

@spring-projects-issues spring-projects-issues commented Dec 12, 2011

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?

Loading

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Dec 13, 2011

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.

Loading

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Dec 13, 2011

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

Loading

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Dec 20, 2011

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

Loading

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Nov 12, 2019

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

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant