Is your feature request related to a problem? Please describe.
This feature request is related to a problem. I'm building an LLM client with support for multiple providers, using Lingoose as a base library due to its great architecture and required level of abstractions.
I store messages and threads in a database with IDs. To improve integration between Lingoose and my database, it would be beneficial to have an optional field with Meta type in the Thread and Message types. This would allow me to store the db_id in meta data for matching Lingoose thread and message IDs with my database threads and messages.
Describe the solution you'd like
I propose adding a Metadata field to both the Thread and Message data types, along with a WithMetadata() method that enables declarative metadata instantiation.
Describe alternatives you've considered
I've considered two alternative approaches:
- Matching messages by their text content. However, this approach is complicated due to the possibility that a single message may contain an array of contents.
- Implementing a matching mechanism for threads based on their content. Unfortunately, this would be even more computationally complex than matching individual messages by content.
Unfortunately, our current Thread implementation does not support storing IDs, which further complicates these alternatives.
Additional context
To simplify the usage of the Meta type across Lingoose and on app level (like my client), I suggest adding pointer methods. This would provide consistent method declarations and struct modifications by other methods.
Specifically, I propose the following additional methods:
- --- Serialization
func (m *Meta) String() string - Use a pointer instead of a value to ensure consistency in method declarations.func (m *Meta) UnmarshalJSON(data []byte) errorfunc (m *Meta) MarshalJSON() ([]byte, error)- --- Single entry
func (m *Meta) Get(key string) interface{} - Returns nil if the key is not declared.func (m *Map) Set(key string, value interface{}) *Map - Allow to chain Set's.func (m *Meta) Has(key string) boolfunc (m *Meta) Remove(key string) bool - Returns true if the key is deleted and false otherwise.- --- All entries
func (m *Meta) Keys() []stringfunc (m *Meta) Values() []interface{}func (m *Meta) Entries() []struct { Key string Value interface{} }func (m *Meta) Clear() - Remove all keys- --- The map size
func (m *Meta) Size() int
This set of methods would provide a more comprehensive and user-friendly interface for interacting with the Meta type.
Please let me know if proposal above works for you and I can make PR
Is your feature request related to a problem? Please describe.
This feature request is related to a problem. I'm building an LLM client with support for multiple providers, using Lingoose as a base library due to its great architecture and required level of abstractions.
I store messages and threads in a database with IDs. To improve integration between Lingoose and my database, it would be beneficial to have an optional field with
Metatype in theThreadandMessagetypes. This would allow me to store thedb_idin meta data for matching Lingoose thread and message IDs with my database threads and messages.Describe the solution you'd like
I propose adding a
Metadatafield to both theThreadandMessagedata types, along with aWithMetadata()method that enables declarative metadata instantiation.Describe alternatives you've considered
I've considered two alternative approaches:
Unfortunately, our current Thread implementation does not support storing IDs, which further complicates these alternatives.
Additional context
To simplify the usage of the
Metatype across Lingoose and on app level (like my client), I suggest adding pointer methods. This would provide consistent method declarations and struct modifications by other methods.Specifically, I propose the following additional methods:
func (m *Meta) String() string- Use a pointer instead of a value to ensure consistency in method declarations.func (m *Meta) UnmarshalJSON(data []byte) errorfunc (m *Meta) MarshalJSON() ([]byte, error)func (m *Meta) Get(key string) interface{}- Returnsnilif the key is not declared.func (m *Map) Set(key string, value interface{}) *Map- Allow to chain Set's.func (m *Meta) Has(key string) boolfunc (m *Meta) Remove(key string) bool- Returnstrueif the key is deleted andfalseotherwise.func (m *Meta) Keys() []stringfunc (m *Meta) Values() []interface{}func (m *Meta) Entries() []struct { Key string Value interface{} }func (m *Meta) Clear()- Remove all keysfunc (m *Meta) Size() intThis set of methods would provide a more comprehensive and user-friendly interface for interacting with the
Metatype.Please let me know if proposal above works for you and I can make PR