Integrating UUIDs in Manticore Search: Simplifying Data Management
Manticore Search version 28.5.0 and newer introduces a significant enhancement, enabling the use of UUIDs (Universally Unique Identifiers) as the primary document identifier. This update eliminates the need to maintain a mapping between UUIDs from the main database and numeric IDs in Manticore, substantially simplifying data management for developers.
Addressing the Prior Identifier Challenge
Before Manticore Search version 28.5.0, document IDs were unsigned 64-bit integers. If a product in the main database already had a UUID, such as 550e8400-e29b-41d4-a716-446655440000, which was used across events, logs, and API responses, loading this same product into Manticore required assigning it an additional numeric ID. While UUIDs could be stored as a separate string attribute, they did not function as the primary identifier for operations like UPDATE, REPLACE, and DELETE, which still demanded a numeric id. This necessitated an extra layer of data storage and synchronization.
New Capabilities with UUIDs in Manticore
Now, Manticore RT-tables support UUIDs as the document’s primary key. This means developers can use a unified identifier for products or other entities across both their main database and Manticore Search, removing the need for intermediary mapping tables.
Practical Implementation and Next Steps
For those ready to implement this feature, the process involves creating a table with UUID support, performing basic operations via SQL and JSON API, and loading documents through the /bulk interface. All examples and instructions are designed for Manticore Search version 28.5.0 or newer. It is crucial to use the actual UUIDs generated by Manticore in subsequent requests, replacing any placeholders.
Finally, UUIDs as primary IDs in Manticore! I’ve been struggling with the numeric ID mapping for ages, especially when integrating with systems that rely heavily on UUIDs from the get-go. This update makes `UPDATE` and `DELETE` operations so much cleaner. My biggest pain point was always the extra synchronization layer, but this seems to eliminate it entirely. For anyone jumping in, make sure your UUID generation is consistent across your main DB and Manticore to avoid headaches. I’m excited to refactor some of my existing jobs with this.