Also, as for injecting Spring implementation, naturally it is possible, I just never thought that it would be required on top of the ability to inject settings to it. What do you think?

I have 2 classes : Country and City, and I want to index the City Class, with a subindex for every Country.
(250 countries totally, so 250 sub indexes).

@Entity
Country {
@Id
long id ;
String isoCode;
}

@Entity
@Searchable
City{ @SearchableId @Id long id; @SearchableProperty(name="cityName") String name @ManyToOne Country country; }

So, in order to achieve what I want, here is the pseudo code :
mapSubIndex(String alias, Property[] ids){ 1. cityDao.findById(ids[0])); 2. Once I have the City, I can city.getCountry() 3. return country.getName(); }

Problems :
1. Since compass already fetched the instance of City, I find it a little sad to re-query the Dao (I know that there are caching solutions available, but ...) I'd just like the function to pass my entity, or to pass all properties of my entities. Or maybe all the properties that are annotated with some @PassToSubIndexFunction, something like that...

2. I need my Daos to be injected. This isn't really a problem since I am using Spring / AspectJ integration, but I'd still like to avoid using magical dependency injection to avoid making the system impossible to understand by another person..

3. I guess that step is unavoidable, but then it's more my problem than Compass'

Hope that I clearly explained my view. I mean, I may not use the system the way it was intented to work, so if you think this feature clearly doesn't match the sub index vision, you can drop it. However, this would be useful to me to have something like that In the meanwhile, I can always work with the current solution

If you want to perform the hashing based on the city, I would recommend having another id in Compass that has the city name. And if it changes, first delete the old one from compass, and then add the new one. I know that sadly it will probably require "Compass" aware code within your dao that updates a City, but there is no way around it that I can think of.

By the way, what is wrong with using the modulo implementation based on the ids of the City? 250 sub indexes sounds like a big number of sub indexes and might result in poor performance of search. What are you trying to achieve with the sub index hashing?

Basically, what I want to achieve, is a fuzzy search on the city Names. The problem of that is that fuzzy searching is really really really slow, no matter what I do. (3-4 seconds for a 2 million city database). So, what I want to do is split the cities to different indexes (1 sub index per Country), and whenever I have to search for a city, I know what the country is, so that I can use sub indexes.

I guess I could add @SearchableId on the Country field of the city (actually, I didn't think of that either, since it was not a real Id).. I have not even thought of doing that, not sure whether it would work (since it is a ManyToOne relationship..).

However, I guess a JIRA issue isn't really the place to ask for help, so you can mark the feature request as "won't fix", or something similar, and if I have further questions on this topic, I'll post on the forums, which are more suitable for this task

(Just some additional proposition for this issue : Would it be aligned with your design vision if you added a @PassToSubIndexHash annotation, that we could use to annotate beans, and add a Property [] array to the SubIndexHash signature, that contains all the properties marked with this annotation ?

Thanks,
Sami Dalouche

p.s.

Sure, in hindsight, the forum would have been a valid place for this thread. But I can understand why you raised it, that's ok.

Actually, I don't need the DAO, except to implement the getSubIndexes() function, which needs to query the database for all the countries (unless I hard code them...)