►
From YouTube: 2021 07 28 APAC Sharding Group Sync
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
You
know
it's
not
too
late:
8,
30.,
okay,.
B
A
A
B
Yeah
so
should
use
this
the
plc
in
my
screen,
so
I
will
keep
rebasing
every
two
to
three
days
but
feel
free
to
as
well.
C
So
I'm
kind
of
wondering,
because,
like
this,
you
kind
of
mentioned
as
well
that,
like
this
amara,
has
very
terrible
performance.
C
The
question
is
like:
would
you
like,
like
this
approach,
like
that
with
squash
some
set
of
the
comments,
maybe
like
half
of
them,
to
keep
adam
work
still
like
be
revisible
or
maybe
like
even
we
base
adam
work
and
like
open
a
new
mr
on
which
we
would
be
looking
at
because,
right
now,
it's
pretty
terrible
experience.
B
Yeah,
it's
horrible.
I
tried
squashing,
some
I'm
just
worried.
If
we
squash
too
much,
it
becomes
harder
to
fix
conflicts
because
you
you
don't
know
what
we
did.
Oh
yeah,
so
the
small
commits
are
very
nice,
very
easy
to
fix
conflicts.
B
So
I
think
performance-wise
is
gonna,
be
bad
anyway,
even
if
we
have
less
commits,
because
the
diff
is
still
quite
big.
So.
A
C
The
structure
sql
like
is
the
majority
of
the
changes
right
now
anyway,
maybe
maybe
let's
like
let's,
maybe
I
will
just
try
to
open
a
new
mr
and
see
if
this
actually
improves
the
performance.
Maybe
right
from
what
I
saw
in
the
browser
like
a
lot
of
these
problems
were
due
to
many
pipelines
being
there.
This
is
this
is
the
main
problem,
and
maybe
it's
going
to
be
acceptable.
It
just
opened,
as
is
as
a
new
mr
yep,
sounds.
B
Good
yeah
and
then,
if
you
have
the
time,
if
you
can
move
the
poc
script
to
the
first
comment,
then
we
can
use
that
I
have
been
manually
doing
it,
which
is
fine
yeah.
C
C
Larry's
last
visible
pipeline,
it
was
also
amps
axon
play
gabriel.
I
I'm
missing
like
getting
the
because
it's
already
created
okay,
cool,
okay,
I'm
kind
of
thinking
that
I'm
missing
some
rings
because,
like
one
related
for
the
cubing,
they
are
also
related
to
the
curing
that
is
covered
by
the
epic
to
some
extent.
B
So
hey
yeah,
let's
open
a
new
emma,
I
don't
know
how
often
we
rebates
I've
been
just
looking,
maybe
every
four
days
if
it
reaches
a
thousand
commits,
then
we
rebate
it.
C
I'm
not
sure
I
would
like
you
propose
just
like
trying
that
once
a
week
because,
like
I
don't
expect
so
many
things
to
change
over
a
period
and
like
each
rebate
is
gonna
be
associated
with
some
cause
of
like
fixing
the
failures.
So
maybe
we
don't
need
to
do
it.
That
often.
C
D
All
right,
I
don't
have
all
the
context
that
you're
discussing,
but
I'm
kind
of
thinking-
and
we
probably
have
issues
already
talking
about
this
but
part
of
re-basing.
That
is
learning
that
people
have
introduced
new
problems
and
what
we
should
hopefully
be
trying
aiming
towards
is
preventing
people
from
introducing
new
problems
like
as
in
introducing
new
joint
queries
or
so
on.
I
know
adam
is
working
on
preventing
or
detecting
nested
transactions,
but
do
we
have
you
know?
C
I
I
think
it's
still
pretty
hard
right
now
to
do
it,
but
as
soon
as
we
let's
say,
embrace
ci
application
record
stuff,
it
should
be
way
more
straightforward
to
discover
things
doing
cross
boundary
joints,
but
it
still
like
it's
still
pretty
tricky.
To
be
honest,
like
to
discover
these
cross
zones.
D
I'm
wondering
if
we,
if
our
aim
is
to
fix
all
the
cross
joins
before
we
can
introduce
ci
before
we
can
make
ci
fail
when
people
introduce
a
new
cross
join.
That
seems
like
the
straightforward
and
easy
path,
but
it
also
could
lead
to
a
moving
target
that
we
never
reach
so
that
that
is
a
risk
I
mean.
Maybe
we're
moving
faster
than
people
are
adding
cross
joins
and
we
have
a
lot
of
communication
telling
people
to
stop
adding
cross
joins,
but
it's
just
a
thought
that
we
could
end
up
falling
behind.
D
C
I'm
I'm
I'm
kind
of
curious,
because
maybe
one
way
to
like
to
see
these
things
through
is
like,
if
we
rebase
this,
mr
for
let's
say
for
the
for
the
next
three
or
four
subsequent
weeks,
we're
gonna,
see
like
how
many
of
those
would
be,
let's
say,
being
red,
and
maybe
this
would
be
indicative
of
like
that,
how
much
of
the
safeguards
we
need
to
focus
right
now
versus
focus
on
the
on
the
big
picture.
D
Right
so
I
think
what
you're
saying
is
that
as
we
rebased,
we
will
learn
if
we're
getting
closer
or
further
away
from
the
target,
as
we
rebase
we'll
be
bringing
in
fixes
that
are
being
merged,
so
we'll
get
less
to-do's
less
red.
C
D
It
is
but
you're
still
left
with
the
problem
where
you
say:
okay.
Well,
I
can't
merge.
This
schema
will
fail,
you
know,
will
fail
if
cross
joins.
I
can't
merge
that
code
to
ci
until
I've
fixed
all
of
the
examples,
so
you've
still
got
this
possible
moving
target
problem,
where,
like
some
kind
of
dynamic
analysis
like
robocop,
where
you
can
have
an
ignores
list,
would
allow
us
to
merge
now
without
fixing
all
the
problems,
but
it's
difficult,
but
I
it
to
me
it
seems
reasonably
straightforward.
D
I
could
imagine
something
that
intercepted
all
active
record
queries
and
used
a
sql
parser
to
interpret
the
names
of
all
tables
and,
if
the,
if
you
reference
any
table
that
contains
ci
underscore
then
every
table
you
reference
also
has
to
be
said.
I
mean
I
haven't
looked
into
that,
but
it
seems
like
that
shouldn't
be
too
tricky.
Then
that
becomes
part
that
becomes
an
active
record
interceptor
for
all
of
all
of
our
ci
jobs.
D
You
know
the
names
of
the
tables
or
it
could
be
the
file
that
is
under
test.
You
can
probably
use
aspect
test,
syntax
or
something
I
don't
know.
C
So
if
someone
would
have
to
introduce
that
you
would
have
to
follow
the
same
pattern,
something
similar
like
active,
rd,
record-based
transaction
or
maybe
it
would
be
allo
cross,
joins
microschemas
or
something
right.
So
you
have
to
really
mark
that
with
the
issue
and
this
decision
to
discover
this
would
be
probably
like
the
way
to
mark
the
pieces
that
is
broken
today
in
the
transitional
period.
That
would
prevent
the
future
ones.
D
Yeah
well
as
we
learned
from
rubocop
that
is
effective
when
you
have
only
like
you
know
a
few
hundred,
but
if
it's
thousands
of
such
blocks,
then
it's
not
feasible
to
add
them
inline
in
as
robocop
comments,
but
in
your
case
this
would
be
nested
blocks,
syntax
that
would
be
feasible
for
a
hundred.
It
would
be
ugly
for
us
to
have
these
hundred
in
the
code,
but
they'd
also
act
as
a
to-do
list
and
link
to
the
issues
and
everything.
D
So
I
think
it's
not
a
bad
idea
when
we
don't
actually
think
that
we've
got
that
many
based
on
this,
the
grip
that
tong's
done
so
maybe
turning
all
of
those
to-do's
into
code
blocks
that
link
to
issues
and
disallowing
any
more
of
them.
Using
the
similar,
dynamic
analysis
technique,
I
described
could
also
be
a
tactic.
D
Yeah,
I
I
don't
have
a
good
answer,
that
what
is
that
code
block
syntax
logics?
It
could
be
tricky
to
do
the
query.
I
mean
the
query
testing
to
see
if
it's
a
bad
query
may
be
trickier
than
what
I'm
imagining
in
my
head.
But
if
I
think
about
that
whole
thing
through,
it
seems
a
lot
simpler
to
implement
than
the
schema
stuff
and.
B
The
schema
stuff
doesn't
have
to
be
chicken
neck.
The
schema
stuff
actually
can
be.
A
lot
of
the
building
blocks
can
be
committed.
D
Yeah
that
the
chasing
a
moving
target
problem-
I'm
describing
I
mean-
maybe
I'm
just
misinterpreted
what
you
were
saying
there,
but
the
chasing
a
moving
target
problem,
I'm
imagining
is-
is
about
rebasing
that
mr
and
less
about
us
introducing
the
schema
syntax.
The
the
concern
I
have
is
you
can't
introduce
the
schema
syntax
into
ci.
You
can't
say:
ci
is
going
to
use
the
two
separate
schemas
and
prevent
cross
joins
until
all
tests
are
passing
like
we're
just
going
to.
B
We
can,
we
can,
I
think
we
can.
We
can
either
merge
in
the
cm
schema
sting
with
just
the
ci
in
public
altogether
or
we
can
like
merging
the
schema
with
a
separate
set
of
parallel
jobs.
D
I
think
okay,
so
you're
imagining
we
separate
our
aspect
test
suite
into
tests
that
have
the
schema
search
path,
separated
those
are
the
ones
that
are
compliant
and
the
ones
that
are
not
compliant.
They
will
just
use
a
combined
search
path
in
the
test.
B
D
Well,
we'll
be
back
to
chasing
the
same
problem,
which
is
we
need
something
that
compares
the
previous
state
to
say.
You
haven't
introduced
more
regressions
like
it's.
Okay,
allow
failure,
but
you
can't
introduce
new
failures,
so
it
ends
up
being
the
same
practical
where
we
have
a
list
of
the
failures
that
we're
okay
with.
B
Yes,
yes,
my
thinking
is
not
too
much,
but
if
it's
a
lot
then
it's
very
hard
to
handle
it's
definitely.
I
love.
D
Okay,
I
kind
of
get
where
you're
going
in
that,
like
okay,
we
could.
We
could
use
schema
search
path
as
the
tool
for
what
I'm
describing,
which
is
some
dynamic
analysis
that
lets
you
know
of
new
failures,
as
opposed
to
implementing,
as
opposed
to
implementing
a
sql
parser
to
do
it,
which
may
be
heuristic
and
not
as
accurate
as
the
schema
search
path
option,
and
I
think
that's
fine
too,
but
we
do
possibly
introduce
also
like
a
large
cost
to
expanding
our
test
suite.
A
D
D
How
would
how
would
we
know
yeah?
I
don't
know
how
to
implement
something
that
says
these.
This
set
of
tests
was.
This
is
a
new
test.
Failure
that
wasn't
in
the
previous
one.
I
think
that,
from
what
I've
seen,
the
security
features
that
try
to
do
this
stuff
like
they,
you
know,
you've
introduced
a
new
vulnerability
in
this
merge
request.
All
of
these
things
have
like
these
signature,
fingerprinting
problems
where
you
get
all
these
false
positives.
Like
obviously,
mr
has
introduced
2000
security
vulnerabilities,
like
I
feel
we're
going
to
go
down
that
road.
D
C
I
I'm
kind
of
thinking
that
whatever
approach
we
take,
it
needs
to
be
working
in
the
context
of
the
current
tests
so
like.
If
you
have
a
test
violating
it
should
fail.
The
given
tests
in
the
current
test
suits
that
we
have
because
then
like
comparing
two
different
test
results.
It's
gonna
be
pretty
nasty,
but
but
if,
if
you
have
like
your
pg-12,
you
need
running,
it's
gonna
show
you
that
this
does.
It
simply
does
not
it's
not
working
in
the
given
context.
C
The
the
schema
search
path
I
like
getting
these
to
work
like
that.
I
think
the
biggest
challenge
right
now.
It's
like
on
the
infrastructure
side
on
getting
these
rights
because
on
the
development
side,
it
doesn't
seem
that
hard
thing
to
do,
but
getting
the
let's
say
the
proper
search
bar
being
assigned
for
the
current
connection.
I
think
this
is
really
like
the
main
challenge
to
figure
out
how
to
solve
that.
D
On
the
development
side,
my
concern
is:
we
can't
merge
a
c
like
I'm
thinking
from
the
ci
perspective,
we
can't
merge,
schema,
search
paths
such
that
you
have
ci
in
one
connection
and
default
or
whatever
it's
called
in
the
other
one.
We
can't
public.
We
can't
merge
that
to
be
the
way
that
rci
is
configured
until
we
have
ci
green
under
all
joins
working,
but
I
don't
know
you
might
be
talking
about
a
different
problem
when
you
talk
about
infrastructure.
D
I
I
don't
think
we
need
to
act
on
this
now
like
we
could
see
if
we're
falling
behind
that
just
the
concern
I
have
is
just
like.
Okay,
if
we
we
want
to
be
aware
that,
if
we're
falling
behind
the
technique,
we
need
to
approach.
This
is
like
the
rubocop
technique,
where
you
have
all
of
these
allowed
failures,
but
you
can't
introduce
a
new
one
and
they're
all
white
listed
ahead
of
time
for
all
the
ones
we
know
about,
and
they
all
link
to.
D
B
Yeah
we
have
to
see,
and
unfortunately
some
of
this
is
some
of
the
things
that
we
skipped.
It's
not
constraints,
some
of
them
just
pure
just
holding
that
just
does
not
work.
For
example,.
A
B
D
B
D
In
the
interest
of
efficiency,
then
my
suggestion
of
introducing
that
in
ci
is
probably
something
we
can
wait
and
not
tackle.
Now
tackle
the
things
we
know
we
need
to
fix
and
just
assume
people
aren't
gonna
keep
making
it
worse.
People
have
been
informed
pretty
widely
about
the
problem
and
they
know
not
to
should
mostly
know
not
to
introduce
it,
and
we
have
database
reviewers.
That
should
also
be
checking
this.
C
I'm
kind
of
looking
at
we
have
pg
query
loaded,
and
maybe
this
is
the
way
like
to
check
as
part
of
the
current
query.
What
tables
are
if
referenced,
and
actually
there
is
like
this
handy
dot
tables
method
that
gives
you
like
out
of
the
current
query
or
tables
reference
in
the
given
query.
So
maybe
this
is
something
that
we
could
use
for.
This
discover
a
plus
prevention.
D
C
B
C
D
There's
a
risk
of
false
positives.
I
guess
if
they
name
a
table
like
what
what
happens,
if
you
use
a
named
table
in
that
query,
does
it
give
you
that
name
as
well,
because,
like
somebody
might
name,
the
ci
builds
table
as
t
and
in
fact
rails
may
do
that
and
then
we're
going
to
end
up
with
t
being
in
the
list.
C
C
C
A
A
We
also
use
this,
for
you
know
when
we
send
the
exceptions
and
and
the
sequence
to
choose
to
what
is
it
sentry?
You
know
to
sanitize
it
and
remove
the
customer
data
so
for
you
it
also
works.