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
Resolve getting the identity of a record that has been stored in the fuzzy index... #66
Within the database, we need to know a unique key and version for each object, which has historically been provided by passing objects from the database wrapped in a MetaObject.
When we build an index we have historically assumed that the index itself will contain either just attributes, or a key within a field which the user application knows about.
For DumbOrderedSearch, we do not build an index and just iterate through the items in the database which are stored embedded in MetaObject in a table. We send the whole thing to the client in the search results.
For the accelerator pack, we've provided a different approach, allowing either an IWhirlwindItem or a 'nominee' to be returned from the database. This doesn't really fit well with user expectations who expect an item to be stored, and individually referenceable by a unique key, and also to be indexed.
This concern should therefore be handled transparently within the server.
Use cases:
1)
I have an object that has a couple of fuzzy attributes, but a significant amount of other data.
I want to store it and retrieve by @Id
I want to get search results with the @Id, @Version, table, and the attribute scores (and have the option for total score, or a breakdown by scorer)
I want the option to tell the server to 'join' from the index to the table and return the object (perhaps even partially populated)
I want a cache to be used where the objects have already been retrieved for the 'join'
2)
I have a small object for which most attributes are fuzzy indexed and am happy to store the whole object in the index.
I still want to be able to get and delete this object by @Id
This means the object must also be referenced from a table.
This has various practical constraints, which need some careful consideration.
We could embed part of the MetaObject information as fields in the object and access them using an interface that conforms to the methods of MetaObject. This would give the client and server an alternative to wrapping the objects, and could be mandated for the accelerator pack.
Within the database, we need to know a unique key and version for each object, which has historically been provided by passing objects from the database wrapped in a MetaObject.
When we build an index we have historically assumed that the index itself will contain either just attributes, or a key within a field which the user application knows about.
For DumbOrderedSearch, we do not build an index and just iterate through the items in the database which are stored embedded in MetaObject in a table. We send the whole thing to the client in the search results.
For the accelerator pack, we've provided a different approach, allowing either an IWhirlwindItem or a 'nominee' to be returned from the database. This doesn't really fit well with user expectations who expect an item to be stored, and individually referenceable by a unique key, and also to be indexed.
This concern should therefore be handled transparently within the server.
Use cases: 1)
2)
This has various practical constraints, which need some careful consideration.
We could embed part of the MetaObject information as fields in the object and access them using an interface that conforms to the methods of MetaObject. This would give the client and server an alternative to wrapping the objects, and could be mandated for the accelerator pack.