p/index for SQL-style indexes on datastore libraries (i.e., avl)

[moul]

Propose creating a p/index package to set up an indexing mechanism that automatically maintains an index based on a configuration each time a data struct is updated.

Several packages in examples/ manually implement similar logic, storing pointers in multiple avl.Tree instances for different fields.

Details

• Automatic Indexing: Automatically maintain an index based on configuration when a data struct is updated.
• Separation of Concerns: Allow datastores to focus on storing data while the indexer library manages secondary indexes efficiently.
• Simplified Logic: Simplifies writing, reading, and maintaining indexing logic.
• Optimized Implementation: Allows for optimized implementations, such as using a slice for small datasets and switching to an avl.Tree transparently.

Potential usage example

type User struct {
    Username string
    // Other fields...
}
var db = avl.Tree
var id = seqid.ID
db, usernameIdx = index.String(func(entry interface{}) string {
    user := entry.(*User)
    return user.Username
})
db.Set(id.Next(), &User{Username: "manfred"}) 
usernameIdx.Get("manfred")
usernameIdx.Iterate(/*...*/) // sorted by username

Or

var db = avl.tree
db = index.String(db, "username", func(entry interface{}) string {})
db = index.Int(db, "age", func(entry interface{}) int {})
// then we can use db as usual + we have new helpers
db.Get(/*...*/) // standard avl
db.GetByIndex("username", "manfred")
db.IterateByIndex("username")

[linhpn99]

@moul I see the second example appears to be cleaner, however it seems that we would need to define an object implementing the tree and an interface for methods related to indexing. If you're confident, please provide a specific plan, and I will create a PR to address it

[moul]

I prefer the first approach for its versatility, as it can work with any datastore implementation, not just avl.Tree.

I prefer the second approach specifically for avl.Tree.

The underlying logic will likely be similar, and we could expose the two interfaces as independent packages to allow A/B testing and see which approach users prefer.

The p/index feature is the first step in a longer-term plan to provide a userland SQL-like interface.

[notJoon]

It seems to be somewhat related to the previously proposed avlorm(#1467) package. Would it be better to create it as a separate package or add query functionality to the ORM package?

If it's to be created as a separate package, I will work on the ORM. I have something that still in WIP.