search

whirlwind-match / fuzzydb

fuzzydb is a fuzzy matching database engine capable of providing human-like search results that make life much easier for users of websites searching for things like cars, houses, people and jobs.
19 stars 5 forks source link

Provide search and mapping for class type for search results #77

Open nealeu opened 12 years ago

nealeu commented 12 years ago

If we have a database with different entity types, e.g. Cafe, Person, Car (as in current example), then we store them in the same store, and they are currently visible through different repositories.

For M3, we need to nail down how this should be expected to work.

1) CrudRepository could filter the views, indexes etc (complex). Or, we can use one namespace per repository (as already supported in some scenarios), or we find another approach.

2) We provide only one 'repository' and have that be polymorphic, and remember what class to materialize. The @TypeAlias annotation would probably be a good approach, as it would give us a short alias (like table name) for the FQCN, and fits with virtually all other NoSQL store types.

nealeu commented 12 years ago

TypeAlias would be good to implement, but the mapping is not the major issue, it's the user expectation of what is and isn't in a store.

Mongo adds a _class attribute, which I think is what we want. The class should be a discriminator within the most generic type the repo can persist. That type can then be used for query generation.

For fuzzy this gets interesting. If we allow Cafe and Person to go in the same repo, then we should only see Cafe when doing cafeRepo.findMatchesFor() and only see person when doing personRepo.findMatchesFor(), but baseRepo.findMatchesFor() should return both, and hydrate them into the correct object class.