►
From YouTube: 2021 07 05 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
A
B
C
I'm
wondering
about
that
rule.
I
I
something
I
didn't
quite
understand
was
like
we
were
changing.
All
of
the
active
record
base
got
connection
for
application
record.connection,
but
that's
that's
only
part
of
what
we
need
to
do.
Well,
that's
not
actually
going
to
remove
the
fact
that
we're
referring
to
the
wrong
connection
some
of
the
time
in
a
ci
context,
right.
A
Yeah
so
at
some
point,
when
we
I'm
not
sure,
what's
the
progress
of
that,
we
will
have
a
base
class
for
ci,
then
we
will
need
to
go
in
again
and
update
those
models
to
point
to
inherit
from
the
ci
model,
and
at
that
step
you
also
need
to
validate
that
we
are
using
the
right
connection
or
not.
Let's
say
when
you
start.
C
C
So
do
we
need
a
different
rule
that
says
you
can't
refer
to
application
record.connection
from
the
context
of
ci
files,
or
do
we
instead
take
a
different
approach
and
say
you
can't
ever
refer
to
application
record.connection
actually,
and
really,
you
should
only
ever
be
referring
to
stealth.connection
in
the
context
of
a
model
or
something
connection
or
whatever
we
have
access
to
in
the
the
model
context,
and
any
application,
record.connection
or
active
record
based
connection
requires
a
river
cop
override
because,
like
you
know
for
sure
that
that's
right
to
do
in
that
context,
because
there
will
be
a
few
cases
left
over
that's
kind
of
what
I'm
wondering
about
why
the
rule
doesn't
ban
the
use
of
both
of
those
things.
A
C
A
Bill,
for
example-
and
that's
that's
what
you
don't
want
to
do
and
to
be
honest
at
this
point,
I
don't
think
we
can
detect
that
by
statically
analyzing
our
code.
That's
something
we
need
to
do
during
ci
runs.
Maybe
have
some
sort
of
extra
hacking
in
inactive
record
where
we
keep
track
of
the
transactions
and
I
think
there
is
a
transaction
open
on
the
main
database.
And
then
you
make
a
query
on
the
ci
database.
Then
we
raise
some
sort
of
error,
not
sure.
A
A
A
B
Coming
back,
yeah
coming
to
dylan's
point,
I
think
it'd
be
nice
if
you
can
do
that,
but
I
think
the
issue
is
that
the
precisely
the
transaction
problem
like
if
we
have
a
transaction,
that's
many
models,
we
need
application,
record.transaction
or
active
record-based
transaction.
We
can
we
choose
one
or
we
can
or
we
can
choose
that.
Okay,
that's
one
way
to
do
it.
Well,.
C
My
question
is
okay:
if
I'm
thinking
about
that,
what's
the
difference
between
activerecordbase.transaction
and
applicationrecord.transaction,
like
I
don't
understand
getting
rid
of
one
and
changing
it
for
another
when
they're,
both
this
kind
of
global
thing,
that
developers
are
going
to
see
as
meaning.
Oh,
it's,
the
global
transaction
I
covered.
It's.
B
The
same
yeah,
so
my
thinking
is
that
we
can
change.
We
can
split
the
fixing
order
offenses
into
two,
even
as
well
so
for
those
where
it
is
the
same.
We
just
change
the
application
record.
Yes,
it
is
the
same.
I
think
functionality.
I
think
it
makes
no
difference,
but
for
those
we
know
that
functionality
will
make
a
difference,
or
we
know
that
it
has
to
be
converted
to
multiple
databases.
B
C
Thinking
about
it
differently,
then,
because
I'm
just
worried
about
the
possibility
that,
like
we
just
start
prematurely
replacing
too
many
of
them
with
applicationrecord.connection,
and
we
won't
have
any
rubber
cop
failures
left
to
fix
for
the
ci
stuff,
and
I'm
also
worried
about
the
case
where
we
should
be
saying
transaction.
But
the
developer
doesn't
know
about
that,
and
they
just
see
all
these
examples
of
application
record.transactions.
So
they
just
create
an
applicationrecord.transaction
and
then
again
we
resolve
the
rubric
rules.
C
If
apple,
you
know,
I
guess
the
it
is
common
for
us
to
be
doing
transactions
across
multiple
tables.
So
in
that
context
application
record.transaction
makes
sense,
but
maybe
there's
like
another
possibility
where
you
have
to
like
explicitly
say
the
things
that
you're
expecting
to
transact
over
the
tables
that
you're
expecting
a
transaction
or
the
models
in
this
case,
and
we
can
kind
of
tell
you
if
that's
valid
and
we
can
dynamically
enforce
it
in
ci
and
say,
like
you're,
only
allowed
to
deal
with
these
models
in
this
transaction.
C
That
or
like
I
was
kind
of
thinking
about.
Like
I
said,
instead
of
application
record.transaction,
you
are
forced
to
write
multi-table
generic
dot
transaction
or
something
like
that.
It's
like
these
rare,
I
I
don't
know
they
might
not
be
rare
cases.
They
might
be
really
frequent,
but
if
there
were
rare
cases
it
would
just
be
like
more
obvious
the
developer
that
they
were
opting
into
doing
something
that
was
risky
and
that
in
particular,
if
they
start
acting
on
ci
tables.
In
this
context,
then
their
code
is
wrong
and
it
needs
to
be
fixed.
B
Later,
this
adam's
thing
is
bigger
than
transaction
is
every
single
class
method.
C
C
Yeah
yeah
yeah
and
to
execute
something,
but
it
may
as
well
be
dot
connection,
dot,
transaction
and
possibly
that's
how
it's
actually
aliased.
I
don't
know,
but
I'm
just
guessing
like
conceptually,
it's
probably
dot
connection.transaction.do
and
so
like
the
yeah.
The
root
cause
is
somebody
asking
for
a
generic
connection,
and
if
we,
if
we
give
somebody
the
easy
okay,
the
way
to
ask
for
a
generic
connection
is
just
change.
Adult
application
record,
I
feel
like
we've,
maybe
just
shifted
the
problem
somewhere
else
without
actually
well
yeah.
C
It
is,
it
is
conceptually
more
sound
in
that
we
believe
application
record
is
the
model
representation
of
the
shared
class
of
these
of
our
shared
or
main
database
in
gitlab,
and
it's
better
than
active
record
base.
I
kind
of
get
that,
but
it's
not
really
solved
the
actual
problem
we're
trying
to
solve,
which
is
that
if.
B
Wouldn't
thing
start
breaking
once
we
define
a
different
connection
explicitly
for
application
record
and
compared
to
ci,
oh
know,
but
ci
descends
more
application
record.
C
I'll
just
see
I
descend
from
application
workflow.
Well,
no!
What
I
was
thinking
that
the
the
dynamic
analysis,
the
situation
is
what
adam
added
before
we
need
to
like,
detect
that,
if
you're
executing
a
against
a
different
table
well
in
the
context
of
another
transaction,
like
we're
going
to
need
to
do
that
as
a
kind
of
runtime
error
we
implement,
but.
C
I'm
thinking
about
all
of
the
intercepting
active
record
stuff
and
that
stuff
is
implemented
in
a
layer
that
isn't
in
application
record.
It's
like
you,
subscribe
to
sql
active
record
events,
and
then
you
can
intercept
those
requests
and
that
would
probably
be
where
we'd
implement
some
kind
of
checking.
A
Yeah
and
I
was-
I
also
thought
that
we
will
probably
have
more
stuff
in
an
application
record
that
is,
that
is
related
to
the
main
database.
So
maybe
we
will
use
the
rails
6.1,
you
know
defining
replicas
and
maybe
the
future
shots
in
application
record,
and
you
have
a
separate
one
for
ci,
I'm
not
sure.
B
C
Want
to
tackle
incrementally
but
sort
of
thinking,
if,
if
we
were
to
go
down
that
road
like
what
we
actually
maybe
would
want,
is
some
kind
of
main
application
record
in
ci
application
record,
which
both
descent
from
application
record
and
then
applications
but
yeah.
This
is
this:
isn't
you
know
that
would
actually
just
be
like
hundreds
of
line
changes
again,
so
we
want
to
separate
that
out,
but.
C
Yeah
being
explicit
about
all
the
tables
you
expect
to
act
on
in
a
transaction,
maybe
is
not
useful,
I
was
thinking
it
would
be.
Nice
people
be
explicit
and
we
could
detect
that
they
were
trying
to
do
something
wrong.
But
the
thing
I
think
now
is
not
a
good
idea
about
that.
C
And-
and
I
think
the
dynamic
analysis
approach
of
just
detecting
that
you're
trying
to
query
the
ci
database
while
you've
got
an
open
transaction
somewhere
else,
is
probably
the
best
way
for
us
to
just
prevent
those
problems
and
maybe
yeah
I
don't
know,
and
now
I'm
still
kind
of
confused
about
why
switching
to
application
record
helps
as
much.
But
I
don't
know
it
seems
a
little
bit
more
conceptually
sound,
given
our
modeling
but
yeah.
C
A
That
would
be
actually
thinking
about
it.
Maybe
we
could
adapt
the
rule
to
to
first
suggest
to
to
use
the
model,
the
transaction
and
then,
if
you
have
multiple
different
models,
you
can
fall
back
to
application
record.
You
could
also
say
the
documentation
page
about
this
with
some
examples
it
might
be,
but.
C
A
C
Yeah,
I
think
that's
fine,
because
application
record.transaction
or
transacting
over
multiple
tables
is
going
to
be
a
common
enough
pattern
that
we
don't
necessarily
want
to
discourage
it
with
ribocop
and
then
yeah
encouraging
model
in
our
documentation
gives
us
the
added
benefit
that
in
future
any
models
we
want
to
move
to
a
separate,
logical
database.
They
will
already
be
partly
encapsulated
by
the
correct
connection
request,
rather
than
us,
having
more
connections
to
unwind
later
on.
If
we
can
pre-online
them
now,.
A
Yeah
the
next
one
is
also
from
me,
so
I
was
trying
to
set
up
a
pg
bouncer
on
my
local
gpk
and
and
yeah.
What
I've
tried
is
just
what
happens
to
the
rest
application
when
you
are
adding
some
loads,
so
within
some
pages,
and
you
just
kill
all
the
connections
right
away
and
what
I
notice
that,
actually
we
don't
raise
error
right
away,
but
we're
doing
some
some
built-in
retry
already,
which
is.
I
was
very
surprised
to
see
that
it's
actually
working.
A
My
only
problem
is
from
from
the
that
we
are
trying
to
do
this
reply
stuff
between
application.
We
are
going
to
probably
saturate
the
connections
to
puma
because
yeah
those
those
connections
we
just
looked
there
and
incoming
connections-
you're-
probably
not
getting
served.
A
C
B
C
Mechanism
built
in
where
all
of
your
requests
are
being
proxied
by
some
cdn
thing
and
those
requests
make
it
to
the
application
and
the
application
can
respond
with
a
header
to
the
proxy
to
say.
Actually,
I
am
the
wrong
server
to
handle
this
write
request
because
it's
it
was
to
do
with
some
distributed
thing
where
write
requests
are
supposed
to
be
sent
to
the
right
node,
but
it's.
It
seemed
related
to
our
case
in
that
we
could.
A
A
So
how?
How
does
it
take
to
to
finish
the
data
application
to
the
ci
database,
and
then
you
know
really
enable
the
connection,
so
the
application
can
continue.
D
Operate,
I
think
that
we
either
go
and
we
are
sure
that
we're
going
with
one
two
minute
max
or
we
are
going
above
that
so
there
are
two
different
strategies
there.
I
don't
know
if
so,
when.
D
Point
we
should
be
able
to.
We
should
know
that
we
are
going
to
go
with
a
transition
of
maximum
one
minute
and
have
a
different
plan.
If
we
see
that
we
cannot
do
it
in
one
or
two
minutes,
I
don't
know
if
everyone
agrees
with
that,
I
don't
think
that
we
can
cover
both
and
the
solution
for
the
one
minute
and
everything
we
discussed
seems
it's
not
reliable.
It's
not
working
for
many
minutes.
D
We
will
have
to
do
something
different
there
and
accept
the
fact
that
maybe
the
application
we
will
not
will
be
in
full
maintenance
mode
for
a
few
minutes.
C
Yeah,
I
think
that's
how
I'm
thinking
about
it
and
then
pretty
much.
The
only
way
we
can
move
forward
is
just
getting
a
benchmarking
environment
and
actually
running
the
experiment
of
what
it
looks
like,
but
yeah
yeah.
I
don't
know
in
the
meantime,
we
could
you
know
proof
of
concept
and
implement
this
workhorse
retry
mechanism,
where
workhorse
does
the
retries
for
us,
rather
than
doing
it
at
the
database,
labor
layer
or
the
application
rails
layer.
C
For
the
reasons
that
adam
said,
it
reduces
the
amount
of
time
humor
is
holding
on
to
client
requests
and
reduces
puma
resources
and
retrying.
The
whole
request
is
actually
kind
of
a
lot
neater
from
a
code
perspective
than
trying
to
retry
a
partially
failed
transaction
and
trying
to
figure
out
where
you're
at
in
the
query,
stack
to
figure
out
what
what
needs
to
be
retried
in
the
application
code.
So
or
you
could
do
it
in
rack.
But
then
yeah,
that's
similar
to
me,
trying
at
the
workhorse
level
just
holds
on
human
connections.
Longer.
D
And
also
we
have
seen
with
some
issues
we
had
with
load
balancer
and
with
after
commits
and
some
other
types
of
hooks
that
sometimes
it's
very
tricky
to
handle
failed
transactions,
and
sometimes
things
happen
that
we
don't
expect
like
at
failed
transaction
and
then
the
load
balancer,
trying
again
and
rails
thinking
that
the
previous
part
was
successful
and
there
are
a
lot
of
tricky
edge
cases
there
to
solve.
If
you
go
lower
level.
A
C
Potentially
is
an
interesting
experiment
for
future
migrations
that
we
believe
we
can
get
down
to
a
few
seconds.
Transition
cut
overs,
and
that
was
exactly
the
same
thing.
We're
talking
about
re-sharding
when
we
were
looking
into
sharding
things
re-sharding
would
take
would
result
in
a
few
seconds
of
downtime.
A
D
C
B
Oh
well,
if
you
want
to
have
a
social
call,
we
can
always
switch
to
somebody's
other
zoom.
It's
not
that
hard.
C
Well,
we
almost
took
up
the
whole
time
we
had.
We
had
a
good
chat
today
anyway,
but
yeah
well
yeah.
It's
ninth
yeah,
it's
53!
So
we
we've
got.