V2 proposals

[funny-falcon]

Please, write your wishes for v2 version of this library.
Tend to write one wish per comment, so others may vote for them separately.

[funny-falcon]

Proposal:
usage of context.Context should be at least possible. It certainly ought to be for connection establishmend and lifetime.
Usage of Context for requests is quite debatable. Probably, it will be possible, but will not be primary interface. Or it will be documented, that for performance reason it is better to omit context.

[funny-falcon]

Proposal:
Implement schema reloading: on-demand or automatic (will fix #7).

[eaglemoor]

Add Callback or Listener implementation for response after they come.

[Sulverus]

1. Schema autoreload (net.box-like) if not implemented.
2. Shadring module support. Example:

   import "github.com/dgryski/go-jump"

   // Add optional ShardFunction to client options
   opts := tarantool.Opts{User: "guest", ShardFunction: jump.Hash}
   // Add method ConnectShard
   shardConn, err := tarantool.ConnectShard([]string{"127.0.0.1:3301", "127.0.0.1:3301"}, opts)
   if err != nil {
       fmt.Println("Connection error: %s", err.Error())
   }
   // Shard.insert
   resp, err := shardConn.Insert(999, []interface{}{99999, "BB"})
   if err != nil {
     fmt.Println("Error", err)
     fmt.Println("Code", resp.Code)
   }```

[eaglemoor]

@Sulverus I think, sharding is a business logic. Not connection library. You can use connections pool and func (p *Pool) Conn(id int) *tarantool.Connection to implement sharding in your code.

[Sulverus]

Ok. So my vote for schema reloading (it's already implemented in lua netbox and probably in python client)

[bofm]

Virtual cursors.

Given an index, an iteration order and a batch size, provide an easy way to lazy-iterate over the indexed data.

[eaglemoor]

@bofm can you give some examples ?

[eaglemoor]

v2 add more examples & benchmarks with Docker Tarantool

[funny-falcon]

@bofm

Virtual cursors.
Given an index, an iteration order and a batch size, provide an easy way to lazy-iterate over the indexed data.

It could be done by remembering last "key" and issueing next query with "> last_key", if there is an btree index.
Do you recognize, there is no way to make it consistent? ie there will be no any transaction isolation.

I suppose, it could be done as a helper. But not sure. To extract "key" from typed record, a lot of magic should happen. Since there are custom deserializers (DecodeMsgpack), looks like there will be separate user-given function to extract keys.

[funny-falcon]

btw, everyone is happy with vmihailenco/msgpack ?
Or is there more preffered library across go-tarantool users?

[eaglemoor]

vmihailenco/msgpack is default native msg pack library, no? But I think we need and support Big.* type :))

[AlekSi]

I wish there were the CHANGELOG.md and tagged releases.

[FZambia]

Had a time to experiment with Tarantool, created an opinionated client https://github.com/FZambia/tarantool based on this one - maybe some of its changes will be interesting for v2, sorry for not sending pr @funny-falcon - too many changes, it's pretty hard to imagine there will be a full match in vision.

[oleg-jukovec]

Let me summarize the my ideas:

#7
#129
#136
#211
#235
#236
#237
#238
#239
#240
#241

There are no critical changes in the API here. Some incompatibilities are expected, but it doesn't seem like too much.

I will be glad to any suggestions.