* Release notes for 15.0.3
Signed-off-by: Matt Lord <mattalord@gmail.com>
* Release commit for 15.0.3
Signed-off-by: Matt Lord <mattalord@gmail.com>
* Rename directory
Signed-off-by: Matt Lord <mattalord@gmail.com>
* Update changelog/15.0/15.0.3/release_notes.md
Signed-off-by: Florent Poinsard <35779988+frouioui@users.noreply.github.com>
---------
Signed-off-by: Matt Lord <mattalord@gmail.com>
Signed-off-by: Florent Poinsard <35779988+frouioui@users.noreply.github.com>
Co-authored-by: Florent Poinsard <35779988+frouioui@users.noreply.github.com>
* Switch to `pflag` for all parsing
This transparently swaps the cli parsing library used by `internal/flag`
from the standard library `flag` package to `spf13/pflag`.
It also introduces hook points for packages throughout the vitess codebase
to register their flags for either all commands using `servenv` or a
particular subset of commands. This allows these packages to continue to
define their flag variables in a package-private way, but without
polluting the global flagset.
Signed-off-by: Andrew Mason <andrew@planetscale.com>
* Workaround exit code difference between stdlib `flag` and `pflag`
tl;dr stdlib `flag` has [this][1] and `pflag` does not
[1]: dcf0929de6
Signed-off-by: Andrew Mason <andrew@planetscale.com>
* adjust test data for difference in spacing between pflag/stdflag
Signed-off-by: Andrew Mason <andrew@planetscale.com>
* update lingering legacy flag tests
Signed-off-by: Andrew Mason <andrew@planetscale.com>
* Update vtgate/tabletgateway.go to use new interface to isolate flags, update test data
Signed-off-by: Andrew Mason <andrew@planetscale.com>
* update flags in java test code
Signed-off-by: Andrew Mason <andrew@planetscale.com>
* feat: add parsing for bitnums
Signed-off-by: Manan Gupta <manan@planetscale.com>
* test: add invalid cases to tests
Signed-off-by: Manan Gupta <manan@planetscale.com>
* feat: normalize bitnums to bit vals too
Signed-off-by: Manan Gupta <manan@planetscale.com>
* feat: add normalization for bit literals
Signed-off-by: Manan Gupta <manan@planetscale.com>
* feat: parameterize binary value to hex
Signed-off-by: Harshit Gangal <harshit@planetscale.com>
* test: added e2e test in vtgate and vttablet
Signed-off-by: Harshit Gangal <harshit@planetscale.com>
* fix: fix the type conversion from hexnum and hexval to binary
Signed-off-by: Harshit Gangal <harshit@planetscale.com>
* test: refactor test
Signed-off-by: Harshit Gangal <harshit@planetscale.com>
* fix: return varbinary and flaghex for hexval and hexnum in eval engine typeOf
Signed-off-by: Harshit Gangal <harshit@planetscale.com>
* test: separate expectation for mysql and vitess result
Signed-off-by: Harshit Gangal <harshit@planetscale.com>
* test: fix test expectation
Signed-off-by: Harshit Gangal <harshit@planetscale.com>
* feat: added bitnum bind variable and test
Signed-off-by: Harshit Gangal <harshit@planetscale.com>
* proto: vtadmin side update
Signed-off-by: Harshit Gangal <harshit@planetscale.com>
* test: fixed test and added more bitnum bind var test
Signed-off-by: Harshit Gangal <harshit@planetscale.com>
* added license header
Signed-off-by: Harshit Gangal <harshit@planetscale.com>
Co-authored-by: Manan Gupta <manan@planetscale.com>
Bumps `log4j2.version` from 2.13.0 to 2.13.3.
Updates `log4j-api` from 2.13.0 to 2.13.3
Updates `log4j-core` from 2.13.0 to 2.13.3
Signed-off-by: dependabot[bot] <support@github.com>
We're doing some feature work on a fork of Vitess where this
synchronized instance lock is creating extra pausing in our client
application. The only state the connection maintains is the RpcClient,
which GRPC should not have a need to be synchronized.
We've removed this blocks in our fork and run some overall query load
testing (nothing explicitly targeting this code block, just throwing a
bunch of transaction reads and inserts through the client). We didn't
encounter any noticeable issues with the change.
Reading the code, the only thing that seems stateful to me is the
VtSession maybe racing between the check to allow a call and then
setting the `lastCall` after constructing the new `SQLFuture`. However,
I don't think an instance lock on the `VTGateConnection` would prevent
anyone else from racing against the `VTSession` instance? I do not have
complete understanding, this is just my surface level observation.
Signed-off-by: Rich Marscher <rmarscher@hubspot.com>
Matt Lord
Florent Poinsard
Florent Poinsard
Rameez Sajwani
Andrew Mason
Harshit Gangal
Deepthi Sigireddi
dependabot[bot]
Dirkjan Bussink
Andrea Cosentino
Andrew Mason
Rohit Nayak
Vicent Marti
Alkin Tezuysal
Andres Taylor
Toliver Jue
Rich Marscher
Sugu Sougoumarane