Provide a collectionName in MongoMappingEvents [DATAMONGO-1256]

[spring-projects-issues]

Wojciech Frącz opened DATAMONGO-1256 and commented

I use repository events to update my search index. Search index names correspond to collection names in my database.

Often, I'm able to recognize the collection name based on the object being saved. But I'm unable to do so when someone pulls the object directly from MongoTemplate, changes and saves it back.

IMHO, events should contain info about collection name where the object is being saved to / removed from. It does not look that difficult (see attachment)

---

Attachments:

• event.jpg (30.88 kB)

Referenced from: pull request #316, and commits 6b5e78f, f22e106, b4118eb, 7634943, 1bac780, 3e485e0

[spring-projects-issues]

Christoph Strobl commented

How about obtaing the collection name via the event.source object?

template.getCollectionName(beforeSaveEvent.getSource().getClass());

[spring-projects-issues]

Wojciech Frącz commented

It is easy when I have custom entity class, indeed. But I'm talking about something like:

DBObject entity = new BasicDBObject();
// some complex initialization of its structure
template.save(entity, "customCollection");

There is no way to get "customCollection" value from the BeforeSaveEvent.

However, these are rare cases. We operate on DBObjects only when we need to change something in the data before "real" entity class is instantiated - i.e. add or remove a field due to implementation changes. Still, it is problematic

[spring-projects-issues]

Oliver Drotbohm commented

Christoph Strobl - That's what I thought as well at first but then stumbled across the custom collection name scenario Wojciech Frącz describes. Should be an easy fix though and can make it into Gosling RC1

[spring-projects-issues]

Oliver Drotbohm commented

A few remarks:

• I don't think it's a good idea to invoke both even handling methods independent from one another in AbstractMongoEventListener. That's basically equivalent to submitting the event twice. I think we should rather call the method taking the domain object only from the method taking the event. That way, overriding the method taking the event will automatically shortcut the other method, so that implementations migrating don't accidentally handle the event twice.
• We should take the chance to polish the Javadoc in AbstractMongoEventListener, too. Please make sure the methods and constructors have at least a summary comment, every parameter is described and we use the same nullable / non-nullabe phrase like everywhere else in the codebase ("must not be {@literal null}.", "will never be {@literal null}", "can be {@literal null}").

Looks good beyond that :)

[spring-projects-issues]

Christoph Strobl commented

Updated PR including delegate from new API to old one as well as some java doc