SourceForge.net Logo
Main Overview Wiki Issues Forum Build Fisheye
Issue Details (XML | Word | Printable)

Key: CMP-608
Type: Improvement Improvement
Status: Open Open
Priority: Minor Minor
Assignee: Shay Banon
Reporter: Ben Dotte
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Compass

Defer calls to insert/delete/save on the CompassSession to a narrowly-defined interface

Created: 03/Apr/08 11:56 AM   Updated: 04/Apr/08 09:38 AM
Component/s: Compass::Core, Compass::Gps
Affects Version/s: 2.0.0 M3
Fix Version/s: None

Environment: Compass 2.0.0M3, Lucene 2.3.1, Hibernate 3.2.5ga


 Description  « Hide
HibernateEventListener and CascadingManager make direct calls to the create(), delete(), and save() methods on CompassSession. We are currently patching these classes and replacing those calls with calls to our own code that queues up index updates and can perform them in batches, as well as retry failed updates.

Instead of doing that, it would be great if Compass deferred those calls to an interface with just those methods, so we could provide our own implementation to Compass and not have to patch those classes.

So something like this:

public interface InternalIndexOperations

{ void create(Object obj) throws CompassException; void delete(Object obj) throws CompassException; void save(Object obj) throws CompassException; }

I guess the existing CompassOperations interface could extend from that to avoid duplication? Then an implementation of this could be provided as a setting perhaps.

I can provide a patch if the idea makes sense.



 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
Shay Banon added a comment - 04/Apr/08 07:23 AM
Its a very good question if this make sense or not. The main problem with this is the fact that Compass has some guarantees regarding transactional behavior which will break in this case.

Also, in such cases, the question if there is a need to abstract it through the Compass API at all. For example, with the mirror, you can simply inject your own event listeners and then add the changed object to a queue, and when you read things off the queue, you can use Compass for it.


Ben Dotte added a comment - 04/Apr/08 09:38 AM
Fair enough, this isn't a huge deal and I wouldn't want to break something else inadvertently.

I guess another possible approach would be for us to subclass DefaultCompassSession and override the create/delete/save methods there instead. In that case we would still need to be able to provide the alternate implementation to Compass, however.

If that idea would also cause problems, I'm okay with just leaving things as-is.