[v2] Rename Call17 to Call and Call to Call16 #125
Assignees
Labels
Comments
Totktonada
added
teamE
code health
AnaNek
added a commit
that referenced
this issue
Apr 23, 2022
An incompatible change was introduced in Tarantula 1.7 which was released in 2016. This change is about a new binary protocol command for CALL, which no more restricts a function to returning an array of tuples and allows returning an arbitrary MsgPack/JSON result, including scalars, nil and void (nothing). We should be in-line with tarantool here and provide `Call17` as just `Call` and rename current `Call` to `Call16`. Closes #125
AnaNek
added a commit
that referenced
this issue
Apr 24, 2022
An incompatible change was introduced in Tarantula 1.7 which was released in 2016. This change is about a new binary protocol command for CALL, which no more restricts a function to returning an array of tuples and allows returning an arbitrary MsgPack/JSON result, including scalars, nil and void (nothing). We should be in-line with tarantool here and provide `Call17` as just `Call` and rename current `Call` to `Call16`. Closes #125
AnaNek
added a commit
that referenced
this issue
Apr 25, 2022
An incompatible change was introduced in Tarantool 1.7 which was released in 2016. This change is about a new binary protocol command for CALL, which no more restricts a function to returning an array of tuples and allows returning an arbitrary MsgPack/JSON result, including scalars, nil and void (nothing). We should be in-line with tarantool here and provide `Call17` as just `Call` and rename current `Call` to `Call16`. Closes #125
AnaNek
added a commit
that referenced
this issue
Apr 26, 2022
An incompatible change was introduced in Tarantool 1.7 which was released in 2016. This change is about a new binary protocol command for CALL, which no more restricts a function to returning an array of tuples and allows returning an arbitrary MsgPack/JSON result, including scalars, nil and void (nothing). We should be in-line with tarantool here and provide `Call17` as just `Call` and rename current `Call` to `Call16`. Closes #125
AnaNek
added a commit
that referenced
this issue
Apr 27, 2022
An incompatible change was introduced in Tarantool 1.7 which was released in 2016. This change is about a new binary protocol command for CALL, which no more restricts a function to returning an array of tuples and allows returning an arbitrary MsgPack/JSON result, including scalars, nil and void (nothing). We should be in-line with tarantool here and provide `Call17` as just `Call` and rename current `Call` to `Call16`. Closes #125
AnaNek
added a commit
that referenced
this issue
Jun 17, 2022
An incompatible change was introduced in Tarantool 1.7 which was released in 2016. This change is about a new binary protocol command for CALL, which no more restricts a function to returning an array of tuples and allows returning an arbitrary MsgPack/JSON result, including scalars, nil and void (nothing). We should be in-line with tarantool here and provide `Call17` as just `Call` and rename current `Call` to `Call16`. Closes #125
AnaNek
added a commit
that referenced
this issue
Jun 17, 2022
An incompatible change was introduced in Tarantool 1.7 which was released in 2016. This change is about a new binary protocol command for CALL, which no more restricts a function to returning an array of tuples and allows returning an arbitrary MsgPack/JSON result, including scalars, nil and void (nothing). We should be in-line with tarantool here and provide `Call17` as just `Call` and rename current `Call` to `Call16`. Closes #125
AnaNek
added a commit
that referenced
this issue
Jun 17, 2022
An incompatible change was introduced in Tarantool 1.7 which was released in 2016. This change is about a new binary protocol command for CALL, which no more restricts a function to returning an array of tuples and allows returning an arbitrary MsgPack/JSON result, including scalars, nil and void (nothing). We should be in-line with tarantool here and provide `Call17` as just `Call` and rename current `Call` to `Call16`. Closes #125
AnaNek
added a commit
that referenced
this issue
Jun 20, 2022
An incompatible change was introduced in Tarantool 1.7 which was released in 2016. This change is about a new binary protocol command for CALL, which no more restricts a function to returning an array of tuples and allows returning an arbitrary MsgPack/JSON result, including scalars, nil and void (nothing). We should be in-line with tarantool here and provide `Call17` as just `Call` and rename current `Call` to `Call16`. For backward compatibility in current `go-tarantool` version build tag `go_tarantool_call_17` have been defined. This tag used to change the default `Call` behavior from `Call16` to `Call17`. Closes #125
AnaNek
added a commit
that referenced
this issue
Jun 20, 2022
An incompatible change was introduced in Tarantool 1.7 which was released in 2016. This change is about a new binary protocol command for CALL, which no more restricts a function to returning an array of tuples and allows returning an arbitrary MsgPack/JSON result, including scalars, nil and void (nothing). We should be in-line with tarantool here and provide `Call17` as just `Call`. For backward compatibility in current `go-tarantool` version build tag `go_tarantool_call_17` have been defined. This tag used to change the default `Call` behavior from `Call16` to `Call17`. Closes #125
oleg-jukovec
pushed a commit
that referenced
this issue
Jun 20, 2022
An incompatible change was introduced in Tarantool 1.7 which was released in 2016. This change is about a new binary protocol command for CALL, which no more restricts a function to returning an array of tuples and allows returning an arbitrary MsgPack/JSON result, including scalars, nil and void (nothing). We should be in-line with tarantool here and provide `Call17` as just `Call`. For backward compatibility in current `go-tarantool` version build tag `go_tarantool_call_17` have been defined. This tag used to change the default `Call` behavior from `Call16` to `Call17`. Closes #125
oleg-jukovec
added a commit
that referenced
this issue
Jul 27, 2022
Overview
This release adds a number of features. The extending of the public API
has become possible with a new way of creating requests. New types of
requests are created via chain calls:
selectReq := NewSelectRequest("space").
Context(ctx).
Index(1).
Offset(5).
Limit(10)
future := conn.Do(selectReq)
Streams, context and prepared statements support are based on this
idea:
stream, err := conn.NewStream()
beginReq := NewBeginRequest().Context(ctx)
if response, err := stream.Do(beginReq).Get(); err != nil {
selectFuture := stream.Do(selectReq)
commitFuture := stream.Do(NewCommitRequest())
// ...
}
```
Breaking changes
NewErrorFuture function removed (#190).
`IPROTO_*` constants that identify requests renamed from
`<Name>Request` to `<Name>RequestCode` (#126)
New features
SSL support (#155).
IPROTO_PUSH messages support (#67).
Public API with request object types (#126).
Support decimal type in msgpack (#96).
Support datetime type in msgpack (#118).
Prepared SQL statements (#117).
Streams and interactive transactions support (#101).
`Call16` method, support build tag `go_tarantool_call_17`
to choose default behavior for `Call` method as Call17 (#125)
Bugfixes
Add `ExecuteAsync` and `ExecuteTyped` to common connector
interface (#62).
Merged
oleg-jukovec
added a commit
that referenced
this issue
Aug 2, 2022
Overview
This release adds a number of features. The extending of the public API
has become possible with a new way of creating requests. New types of
requests are created via chain calls:
selectReq := NewSelectRequest("space").
Context(ctx).
Index(1).
Offset(5).
Limit(10)
future := conn.Do(selectReq)
Streams, context and prepared statements support are based on this
idea:
stream, err := conn.NewStream()
beginReq := NewBeginRequest().Context(ctx)
if response, err := stream.Do(beginReq).Get(); err != nil {
selectFuture := stream.Do(selectReq)
commitFuture := stream.Do(NewCommitRequest())
// ...
}
```
Breaking changes
NewErrorFuture function removed (#190).
`IPROTO_*` constants that identify requests renamed from
`<Name>Request` to `<Name>RequestCode` (#126)
New features
SSL support (#155).
IPROTO_PUSH messages support (#67).
Public API with request object types (#126).
Support decimal type in msgpack (#96).
Support datetime type in msgpack (#118).
Prepared SQL statements (#117).
Streams and interactive transactions support (#101).
`Call16` method, support build tag `go_tarantool_call_17`
to choose default behavior for `Call` method as Call17 (#125)
Bugfixes
Add `ExecuteAsync` and `ExecuteTyped` to common connector
interface (#62).
oleg-jukovec
added a commit
that referenced
this issue
Aug 3, 2022
Overview
This release adds a number of features. The extending of the public API
has become possible with a new way of creating requests. New types of
requests are created via chain calls:
selectReq := NewSelectRequest("space").
Context(ctx).
Index(1).
Offset(5).
Limit(10)
future := conn.Do(selectReq)
Streams, context and prepared statements support are based on this
idea:
stream, err := conn.NewStream()
beginReq := NewBeginRequest().Context(ctx)
if response, err := stream.Do(beginReq).Get(); err != nil {
selectFuture := stream.Do(selectReq)
commitFuture := stream.Do(NewCommitRequest())
// ...
}
```
Breaking changes
NewErrorFuture function removed (#190).
`IPROTO_*` constants that identify requests renamed from
`<Name>Request` to `<Name>RequestCode` (#126)
New features
SSL support (#155).
IPROTO_PUSH messages support (#67).
Public API with request object types (#126).
Support decimal type in msgpack (#96).
Support datetime type in msgpack (#118).
Prepared SQL statements (#117).
Context support for request objects (#48).
Streams and interactive transactions support (#101).
`Call16` method, support build tag `go_tarantool_call_17`
to choose default behavior for `Call` method as Call17 (#125)
Bugfixes
Add `ExecuteAsync` and `ExecuteTyped` to common connector
interface (#62).
oleg-jukovec
added a commit
that referenced
this issue
Aug 4, 2022
Overview
This release adds a number of features. The extending of the public API
has become possible with a new way of creating requests. New types of
requests are created via chain calls:
selectReq := NewSelectRequest("space").
Context(ctx).
Index(1).
Offset(5).
Limit(10)
future := conn.Do(selectReq)
Streams, context and prepared statements support are based on this
idea:
stream, err := conn.NewStream()
beginReq := NewBeginRequest().Context(ctx)
if response, err := stream.Do(beginReq).Get(); err != nil {
selectFuture := stream.Do(selectReq)
commitFuture := stream.Do(NewCommitRequest())
// ...
}
```
Breaking changes
NewErrorFuture function removed (#190).
`IPROTO_*` constants that identify requests renamed from
`<Name>Request` to `<Name>RequestCode` (#126)
New features
SSL support (#155).
IPROTO_PUSH messages support (#67).
Public API with request object types (#126).
Support decimal type in msgpack (#96).
Support datetime type in msgpack (#118).
Prepared SQL statements (#117).
Context support for request objects (#48).
Streams and interactive transactions support (#101).
`Call16` method, support build tag `go_tarantool_call_17`
to choose default behavior for `Call` method as Call17 (#125)
Bugfixes
Add `ExecuteAsync` and `ExecuteTyped` to common connector
interface (#62).
oleg-jukovec
added a commit
that referenced
this issue
Aug 4, 2022
Overview
This release adds a number of features. The extending of the public API
has become possible with a new way of creating requests. New types of
requests are created via chain calls:
selectReq := NewSelectRequest("space").
Context(ctx).
Index(1).
Offset(5).
Limit(10)
future := conn.Do(selectReq)
Streams, context and prepared statements support are based on this
idea:
stream, err := conn.NewStream()
beginReq := NewBeginRequest().Context(ctx)
if response, err := stream.Do(beginReq).Get(); err != nil {
selectFuture := stream.Do(selectReq)
commitFuture := stream.Do(NewCommitRequest())
// ...
}
```
Breaking changes
NewErrorFuture function removed (#190).
`IPROTO_*` constants that identify requests renamed from
`<Name>Request` to `<Name>RequestCode` (#126)
New features
SSL support (#155).
IPROTO_PUSH messages support (#67).
Public API with request object types (#126).
Support decimal type in msgpack (#96).
Support datetime type in msgpack (#118).
Prepared SQL statements (#117).
Context support for request objects (#48).
Streams and interactive transactions support (#101).
`Call16` method, support build tag `go_tarantool_call_17`
to choose default behavior for `Call` method as Call17 (#125)
Bugfixes
Add `ExecuteAsync` and `ExecuteTyped` to common connector
interface (#62).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
CALL_16behaviour may be confusing, especially for new users. Say, one returns a scalar from a function, but receive an array in this place in the connector (not counting one extra array for multireturn support). We should be in-line with tarantool here and provideCALL_17as justCall.This is a breaking change and I propose to do it after we'll resolve most of more annoying problems (such as support decimals, contexts, master discovery, SQL).
There is a more gentle way to do so: keep API that is offered by
import "github.com/tarantool/go-tarantool"as is, implement the new one asimport "github.com/tarantool/go-tarantool/v2"or so and replace the former with the latter in README and docs. Anyway, it requires a careful planning of v2, so I still propose to return here somewhere around end of Q1'2022.Ideas? Suggestions?
The general discussion about v2 features: #65.
The text was updated successfully, but these errors were encountered: