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.
We want to supply the same UUID as the @Id both in fuzzydb and another database, such as MongoDB, when using fuzzydb as an in memory index backed by MongoDB. Without this, using Repository.save() to update an existing item across both repositories is difficult.
The following should work
@Id
private UUID id;
This should be the preferred option over the following
@Id
private String fuzzydbRef;
Superficially, for a short String, the memory footprint is comparable. UUID has the advantage of a smaller disk footprint, and also being one object, in comparison to String's two (String and char[]).
In reality, UUID is worse as we have to maintain an index in order to be able to find the item.
The short-term preferable workaround is to store the fuzzydb Ref in the mongodb document and either use fuzzydb for all searches, or provide a bi-directional link to allow the mongodb document to be also found from the fuzzydb document.
As an application can populate a UUID, then this would be a case of persisting the fuzzydb item first, and then applying that to the mongodb document.
The problem here is that the ref would also have to be updated when re-populating a fresh fuzzydb instance.
Supporting UUID as the primary key in fuzzydb therefore remains a valuable feature
We want to supply the same UUID as the @Id both in fuzzydb and another database, such as MongoDB, when using fuzzydb as an in memory index backed by MongoDB. Without this, using Repository.save() to update an existing item across both repositories is difficult.
The following should work
This should be the preferred option over the following
Superficially, for a short String, the memory footprint is comparable. UUID has the advantage of a smaller disk footprint, and also being one object, in comparison to String's two (String and char[]).
In reality, UUID is worse as we have to maintain an index in order to be able to find the item.
The short-term preferable workaround is to store the fuzzydb Ref in the mongodb document and either use fuzzydb for all searches, or provide a bi-directional link to allow the mongodb document to be also found from the fuzzydb document.
As an application can populate a UUID, then this would be a case of persisting the fuzzydb item first, and then applying that to the mongodb document.
The problem here is that the ref would also have to be updated when re-populating a fresh fuzzydb instance.
Supporting UUID as the primary key in fuzzydb therefore remains a valuable feature