►
From YouTube: 2021 07 14 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
B
A
A
C
We
can
start
my,
I
think,
apart
from
chin's
out
of
mind,
was
first
on
the
agenda.
A
lot
of
this
has
already
been
had
async
and
somewhat
between
me
and
tong
anyway,
yeah.
So
I'm
not
sure
if
there's
anything
else
to
be
discussed
there
with
anybody
else.
If
nobody
else
has
opinions
on
this,
do
you
want
to
voice
over
anything
you'd
written
down.
C
A
Yeah,
so
I
think
basically,
what
we
discussed
was
that
discussed
previously
shipping
ci
instance
variables
to
staging.
If
not,
this
is
ci
staging
variables
on
a
different
argument,
but
if
we're
not
shipping
it,
then
I'm
wondering
whether
we
should
like
change
the
ci
database
to
mirror
instead,
and
I
think
that
is
what
camille
has
implemented
in
the
poc,
mr
as
well.
So
does
anyone
have
any
objections
to
that.
C
Where
are
you
saying
that
we've
changed
the
poc
now
to
mirror
the
database
schemas
and
only
have
one
schema
or.
C
I
see
okay
yeah,
I
missed
that
update
and
then
we'll
still
plan
on
using
the
schema
search
path
to
remove
that
to
make
it
difficult
or
to
notify
us
of
joins.
Yes,.
C
C
Camille,
do
you
want
to
clarify
for
us?
I
I
haven't
looked
into
that.
What's
what
is
the
current
plan
with
the
structured
sql
files
and
the
database
migrations
directory?
Are
we
going
to
just
have
one
now
or.
B
So
this.
C
B
Yes,
basic,
yes,
as
for
the
migration,
this
is,
I
think
it
should
probably
work,
but
there
is
like
this
problem
with
the
concurrency
as
well.
I'm
not
sure
like
if
we
ever
execute
like
db
migrate
concurrently
across
like
men
and
servers,
but
if
you
would
execute,
let's
say
main
lci
concurrently,
it
would
simply
be
like
a
problem
because
you
would
be
inserting
probably
like
twice
or
out
of
the
order.
B
So
if,
if
we
go
like
with
a
single
structure,
sql
but
use
logical
partitioning
using
schemas,
the
model
has
to
be
that,
like
your
single
connect
that,
like
you
for
a
logical
database,
you
always
have
only
one
connection
and
you
can
use
many
connections,
but
they
have
to
point
to
different
logical
databases
to
ensure
that
you
can
always
like
fully
manage
db
structures
schema
migrations
separately.
B
B
I'm
kind
of
like
thinking
that
we
likely
should
have
like
maybe
common
db,
slash
migrate,
like
a
sim
link,
as
we
have
now,
but
probably
separate
db,
schema
migrations.
Folders
that
you
add
your
migrations
into
because
then
you
kind
of
run
into
the
problem
that
you
are
kind
of
seeing
right
now
as
well
tonight.
C
How,
where
we're
landing?
How
does
this
differ
from
what
andreas
was
trying
to
propose?
Where
I
mean
address,
is
one
structure
sql
file,
one
database,
migrations
directory
and
yeah?
Presumably,
you
just
run
the
migrations
and
they're
kind
of
important.
So
nothing
happens.
You
run
the
crm
migrations
after
the
other
migrations.
B
Like
it's
very
similar
to
andrea's
proposal,
but
there
are
like
a
few
things
yet
to
discover
exactly
how
we
want
to
do.
For
example,
we
did
not
yet
define
exactly
how
migration
is
going
to
behave
when
you
execute
them
across
to
different
databases.
B
For
example,
you
have
migration,
adding
column
to
the
projects
or
adding
current
to
the
ci
or
running
something
more
complex
than
like,
adding
columns
like
background
migration,
you
effectively
need
to
replicate
this
migration
twice
and
like
we
need
to
somehow
figure
out
looking
at
these
migrations
that
are
being
added.
How
are
you
gonna
handle
them
if
they
actually
like
work
across
two
different
databases,
because,
like
the
last
thing
you
really
want
to
do
is
like
you
have?
B
B
What
we
actually
gonna
do
then,
like
do
we
gonna,
replicate
the
all
migrations
for
the
ci.
Also,
on
this
let's
say
stair
data
that
are
on
the
main
database
or
not
and
like
in
what
cases
we
will
not
decide
to
not
do
each,
but
then
you
kind
of
end
up
in
the
situation
that,
like
you,
have
the
schema
deviation
on
the
running
system.
So
you
cannot
really
maintain
the
same
structure
sql
on
actually
running
system.
The
structures
will
kind
of
represent
a
snapshot
of
your
ideal
structure.
A
C
But
once,
but
once
we
deviate
once
we
break
the
replication,
then
because,
prior
to
breaking
the
deviation,
we
will
run
the
ci
migrations,
but
it'll
just
look
like
they've
already
run,
so
we
won't
have
an
issue.
I
I
don't
understand.
I
don't
understand
the
consequences
of
the
asynchronous
migrations
where
the
where
we,
where
it
doesn't
necessarily
know
it's
finished,
to
background
migration,
then
you
kick
off
too
concurrently.
That
could
be
an
issue,
but
so
the
adding
column
example
simple.
C
B
But
it
looks
like
this
is
simple
like
there
are
cases
where
we
are
actually
like
migrating
data
as
well
right,
so
I
I
mean,
like
my
challenge,
is
like
that
we
are
kind
of
replicating
all
migrations
in
all
cases,
and
we
kind
of
need
to
make
a
judgment
call
how
much
we
are.
Okay,
with
like
saying
that
this
migration,
sorry,
this
structure
between
these
two
distinct
databases,
can
deviate
on
different
schemas,
because
this
would
be
actually
like
the
the
outcome.
C
Behavior
migration
that
changes
data
shouldn't
change
structure,
though
so
I'm
kind
of
I'm
wondering
if
we
can
just
like
separate
those
two
concepts
in
some
way
like.
I
agree
that
migrating
changing
data
is
gonna,
be
an
issue,
but
changing
data
against
stale
data
in
a
migration
on
the
ci
database
won't
be
a
problem
because
nobody's
going
to
read
it
and
it
won't
result
in
the
schema
deviation
because
the
data
migration
didn't
change
this
theme.
C
So,
like
you,
you
still
end
up
with
exactly
the
same
schema
at
the
end
of
it.
Let's
end
up
with
weird
inconsistent
data,
but
that
with
stale
data
anyway,.
C
Yeah,
I
think
we're
talking
about
post
the
streaming
replication,
because,
prior
to
this,
when
we're
running
stream
replication,
there
will
be
physically
no
way
to
write
the
ci
databases.
You
won't
be
able
to
perform
right
queries
against
them.
They
will
be
read
only
replicas,
they
won't
accept
rights.
Our
migrations
we'll
be
writing
to
the
primary
database
and
whether
we
choose
to
run
it
twice
against
the
primary
database
is
kind
of
just
a
detail.
C
B
That's
why
maybe,
like
I
think,
like
I
still
haven't
made
my
mind
whether
like
common
structure
and
common
migrate,
is
like
the
way
to
go
because
like
in
this
model,
if
you
have
like
migrate
and
separate
ci
migrate,
you
actually
kind
of
make
it
maybe
easier
to
reason
like
in
what
context
what
migration
is
being
wrong,
because
and
it's
pretty
explicit
that
it's
still
like
you-
have
the
deviation
of
the
schema.
B
The
question
is
really
like
how
you,
in
what
circumstances
you
don't
run
migrations
on
on
another
database,
effectively
that
your
schema
search
path
is
different
effect
effectively
because,
like
probably
like
whether
you
run
migration
or
not,
is
dependent
on
your
schema
search
path
for
a
given
connection,
this
probably
would
be
the
criteria
that
we
would
use.
Probably
you
will
add
some
kind
of
attribute
to
your
migration
to
indicate
in
what
schema
this
migration
should
would
should
work
on
to
indicate.
So
maybe
this
would
be
like
the
criteria
to
skip
when
you
don't
run.
C
C
C
We,
I
don't
think
we
can
automate
a
migration
where
they
configure
the
second
database
at
the
same
time
as
us,
because
it
is
a
complicated
operation.
It'd
be
like
expecting
all
of
our
self-managed
customers
to
upgrade
postgres
versions.
At
the
same
time
as
us,
they
can
do
it
ahead
of
us.
They
can
do
it
after
us,
but
we
can't
have
them.
Do
it
at
the
same
time,
because
it's
a
large
data
based
migration.
That
requires
like
these
operational
steps
and
some
brief
window
of
downtime,
and
so.
C
On
so,
let's
say
that
in
in
13
in
14.10
we're
running
two
databases
in
production
in
14.10,
we
want
our
customers
to
still
be
able
to
upgrade
to
14.10
without
having
to
go
through
this
operational
pain
and
splitting
their
database
using
some
complex
documentation
or
even
an
automated
solution.
We
offer
them
because
an
automated
solution
we
offer
them
still
going
to
be
operationally
impactful
and
now
to
pick
a
weekend.
That's
a
big
customer.
So.
B
I'm
kind
of
brought
like
that,
my
like
kind
of
like
expected
timeline
in
the
15.0.
B
We
probably
can
expect
that
all
the
new
installers
will
use
many
databases
cp,
because
we
can
write
provision
and
high
speed
that
and
we
should
divided
by
that,
but
only
like,
probably
in
the
16.0,
which
is
like
another
major
breaking
release
crunch,
we
can
kind
of
expect
that
we
migrate
all
existing
customers
to
this
model
with
some
eye
kind
of
offline
online.
Whatever
method
we
choose,
but
this
is
where
we
like
the
timeline.
We
are
looking
at
maintaining
the
the
the
all
schemas
on
the
main
database
effectively
for
time
being.
C
B
Yes,
but
like,
but
like
we
can
define
it
by
the
by
the
schema
search
buff
on
like
on
on
the
given
connection
or
like
in
the
given
migration.
We
clearly
indicate,
and
we
don't
actually
out
of
defining
planet.
We
just
allow
you
to
define
one
which
kind
of
implies
that
you
cannot
cross
those
schemas.
Simply.
This
is
like
impossible
thing
to
do.
C
Yeah,
that
makes
sense.
I
mean
that
kind
of
forces
people
to
not
write
a
migration
that
kind
of
joins
between
two
different
tables
in
order
to
backfill
data
as
well.
So
that
begs
the
question
about:
when
how
do
we
go
about
denormalizing,
a
bunch
of
data
when
we
come
to
wanting
to
denormalize
data?
We
need
to
do
it
before
we
break
the
schemas.
C
A
B
C
But
we
may
actually
want
to
allow
people
to
write
a
background
migration
that
can
modify
data
across
both
places.
I
mean
thinking
about
the
example
of
denormalizing.
Data
is
one
case
where
we
may
need
to
denormalize
data
across
the
two
databases
and
sidekick
is
part
of
the
rails
app
and
therefore
can
query
both
databases.
B
Sometimes
they
would
write
connection
that
execute
so
I'm
kind
of
like
we
need
to
figure
out
like
the
patterns
for
supporting
vignette
migrations.
B
Where
you
are
explicit
on
the
execution
context
and
like
like
for
the
active
record-based
model,
we
probably
would
have
to
break
our
rule
about
like
not
basing
on
on
like
top-level
objects,
I
would
kind
of
say
that,
like
it's
fine
to
base
your
objects
on
application
record
or
ci
application
record
based
on
the
needs,
I'm
not
sure
about
connection
execute
yet.
C
B
So
all
your
migrations
will
be
executed
just
fine
in
the
in
the
form
that
you
have
them
today
like
execute
method
on
the
dev,
app,
add
column,
arter
table
or
whatever
else
you
do,
it's
gonna
just
behave.
Fine.
The
problem
will
be
with
others.
B
A
B
Large
migrant
migrations
and
like
ability
to
replay
them
and
let's
discuss
like
the
options
or
maybe
like,
because
I
I
think
it's
slightly
different
problem
to
the
common
structure
because,
like
we
may
maintain
the
common
structure,
but
we
may
maintain
separate
folders
or
we
may
maintain
something
different,
so
so,
probably
like
thinking
holistically
about
giving
migration
and
fallout
of
running
across
different
databases,
plus
by
grant
migrations
and
like
how
we
want
to
model
existing
workflows
for
background
migrations
would
be
like
a
good
way
like
to
keep
up.
Keep
us
focused.
Does
this
make
sense?
B
B
A
A
So
I
have
a
question:
what's
the
biggest
problem
with
tagging
is
because
we
use
tagging
syntax
in
multiple
places,
so
I
I
just
wonder:
what's
the
biggest
problem
right
now
with
the
biggest
problem
right
now
is
that
it
cannot
support
it
doesn't
support
multiple
databases.
A
Yeah.
Okay,
I
understand
that,
but
it's
like
okay,
because
in
in
case
of
queuing
we
can
solve
that
through
the
work.
We
are
doing
right
now
that
the
normalizes
taggings
into
ci
tables
right.
So
this
would
move
information
about
tags
already
yeah,
but
if
the
problem
is
that
we
need
to
fix
actually
starting-
wouldn't
it
make
sense.
Yeah
yeah
and
the
only
usage
is
ci.
So.
B
Yes,
the
usage
is
here
right,
but
also
they're
like
in
a
bunch.
In
a
few
places
we
do
filtering
based
on
tax,
so
like
ci's
main
user,
all
that
so
I
think
it
just
makes
sense
to
keep
it
like
close
to
the
ci,
and
we
also
kind
of
see
that
I
think
I
just
this
is
my
perspective
that,
like
in
the
current
form,
taggings
the
way
how
they
are
implemented.
B
B
So
I'm
kind
of
thinking
that
maybe
overall
in
the
future,
we
may
kind
of
simply
work
our
way
on
completely
moving
away
from
timings,
also
as
a
pattern
to
be
used,
because
I
think
it
kind
of
in
a
lot
of
cases.
Pre
creates
more
complications
that
it
helps.
B
Yes,
we
didn't
make
a
decision
deployments
and
environments,
and
I
see
like
some
amount
of
the
failures
is
due
to
these
tables.
I'm
kind
of
like
raising
awareness
of
that.
I
don't
know
about.
C
A
Yeah,
I
mean
it's
quite:
it's
not
straightforward
to
write
a
script
to
see
like
what
the
transitive
things
are
and
how
many
links
are
because
it's
not
just
deployment
it's
deployments
to
environments,
environments
to
projects.
So
what
is
transitive
things?
We've
got
to
take
an
income,
so
the
number,
the
total
number
of
those
associations.
C
Yes,
security
definitely
gets
more
complicated,
but
security
like
I
agree
that
you
don't
want
to
tie
that
to
ci
stuff,
because
those
features
have
a
life
of
their
own
outside
of
ci
environments
and
deployments
are
just
so
simple
that
and
and
really
just
tied
to
build.
I
think
we
can
probably
move
them,
but
yeah.
A
C
Yeah,
if
we
move,
if
we
move
to
environments
and
deployments,
we
might
have
to
move
kubernetes
clusters
and
then
have
ci
in
front
of
them
either,
and
they
will
join
to
those
things.
A.
C
C
I
have
one
more
agenda
item
after
this.
Well,
there's
a
couple
more,
but
nobody
else
is
present,
which
is
like
tactical
about
how
we
want
to
deal
with
that
mode
request.
C
We
currently
have
open,
I
kind
of
find
it
weird
to
try
to
be
fixing
things
and
pushing
them
to
that
merge
request,
because
my
concern
is
we
get
to
the
end
of
that
and
we
still
need
to
break
it
up
right
and
we
still
need
people
to
review
thousands
of
lines
of
changes
but
across
hundreds
of
mode
requests,
and
we
can't
and-
and
then,
like
you
know,
we
we
end
up
delaying
things
much
when
we
have
something
that
works,
but
when
it
works,
that's
not
the
end
point,
because
we
still
have
to
break
it
up
into
hundreds
of
merge
requests.
B
I
I'm
kind
of
thinking
that,
like
right
now,
like
even
on
this,
mr,
like
it's
pretty
apparent
what
some
of
changes
we
need
to
make,
so
we
can
simply
like
kind
of
split
our
focus
on,
like
maybe
me
and
thunk
or
like
me
or
tongue,
just
making
this
more
green
over
time
and,
like
other
people,
just
kind
of
going
and
chipping
biting
some
aspects
of
that,
like
application
record,
probably
being
one
some
connections
being
another.
I
know
that
you
started
fixing
some
features
that
do
cross
noise.
B
Another
thing
could
be
like
disabled
joints.
These
are
the
things
that
we
can
kind
of,
like
start
biting
out
of
that,
mr
so
kind
of
like
splits,
a
focus
on
the
group
of
people
that
is
trying
to
keep
this
as
green
as
possible
on
a
group
of
people.
That
kind
of
like
bites
aspects
of
that
into
smaller
amounts
that,
like
we
can
we
keep
merging
into
muscle
and,
like
we
keep
rebasing.
C
I
think
camille,
if
you
have
like
the
higher
level
view
of
it,
and
maybe
tom
does
as
well
and
since
you're
in
alternative
time
zones.
You
don't
overlap,
you
don't
conflict
with
each
other
much
maybe
it
makes
sense
for
you
to
be
like
kind
of
leaving
an
inline
comment
and
saying
this
is
a.
This
is
a
thing
that
can
be
split
out
like
I
fixed
it
right
here,
but
it
can
be
split
out
and
then
I
can
just
go
ahead
and
tackle
all
of
the
inline
comments
you
have
and
go.
C
I
can
just
create
the
merge
requests,
create
the
test,
assign
the
right
team
and
get
it
through
review.
That
way.
B
Yes,
I
I
was
kind
of
thinking
that,
like
we
start
kind
of
commenting
extensively
on
the
things
to
fix,
like
the
more
we
get
code
coverage
because,
like
I
think
we
are
still
like
in
these
cows
with
this,
mr
I'm
like
trying
to
figure
out
like
the
approach
to
structure
rescue
some
queries,
some
some
tables,
and
things
like
that.
B
Mr
I,
rather
if,
if
you
are
very
keen
into
looking
at
that
in
my
head,
it
looks
like
that,
like
I
just
want
to
make
it
like
more
complete
on
like
the
architecture,
because
it's
that
much
easier
to
reason
about
like
migrations
and
problems
like
how
we
discover
joints.
What
tables
are
there
because
we
still
have
like
these
kind
of
like
reserved
comments
about
like
deployments,
environments
taggings?
C
I
wonder
if
we
can
use
like
a
format
to
mark
the
things
that
are
ready
for
somebody
to
just
do
like,
because
there's
the
high
level
big
problems
you're
talking
about
solving
and
it
doesn't
make
sense
for
other
people
to
tackle
those
outside
of
this
merge
request,
because
they're
big
things,
but
if
there's
like
smaller
things
inside
this
merchandise
or
things
that
we've
already
decided
on
and
they're
just
part
of
this
merge
request.
So
we
can
just
leave
a
comment
with
a
specific
format
and
say
then
that
means
somebody
can
pick
that
up.
C
A
You
something
else
picks
a
great
issue,
but
I'm
thinking
that
anyone
within
charting
group
has
the
context
of
picking
anything
up
right
now.
That's
fine
where
we
want
to
get
more
complete
is
when
we
start
farming
to
other
groups,
it
has
to
be
in
a
more
stable
state.
C
Yeah,
but
there
might
be
things
that
could
be
farmed
out
to
other
teams
now,
but
what
you
actually
need
is
somebody
in
our
team
to
find
that
write
it
down
really
clearly
for
the
other
team
and
be
the
person
who
answers
their
questions
and
say
like
we
need
you
to
change
this
feature
to
stop
joining
from
here
to
here
I'll
describe
to
you.
The
problem
we
ran
into
is
the
possible
solution,
but
you
need
to
figure
this
out
yourself,
yeah,
that's
good!
A
B
Yes
and
like
that's,
that's
the
tricky
part
about
like
the
because,
like
there
are
key
like
cases
where
we
can
make
it
and
like
talk
like,
I
know,
like
you,
for
example,
comment
about
like
how
many
ids
we
plug
to
kind
of
provide
a
limit.
B
This
is
like
the
divided
question
to
have
like
how
we
handle
these
cases,
because
you're
gonna
have
to
plug
in
a
few
cases
through
race,
but
then,
like
the
question
is
also
like,
or
maybe
I'm
kind
of
like
over
arching
that
maybe
maybe
we
can
like
identify
these
places
where
we
clearly
have
to
do
cross
joins,
and
we
pluck
ideas
and
like
we
just
ask
for
changing
them.
A
C
B
Okay,
so
I
I
have
this
suggestion-
maybe
it's
gonna
be
counter
intuitive
right
now
out
of
this
poc.
B
As
for
the
feature
I
most
worried
about
the
security
set
of
the
features,
because
they
are,
I
think
mostly
affected,
would
you
make
sense
like,
for
example,
you
udeland
or
tong,
while
I
kind
of
work
in
something
different
to
focus
on
this
aspect
of
the
poc,
on
figuring
out
the
structure
and
like
documenting
that
to
the
team
and
of
reaching
early
to
the
team
on
on
security
teachers
because,
like
we
need
to
make,
I
think,
a
bunch
of
the
normalization
on
these
features.
B
So
maybe,
instead
of
like
thinking
about
small
problems,
let's
kind
of
focus
on
these
major
problems
to
solve
and
reach
these
teams
early.
B
So
if
you
were
someone,
some
of
you
could
like
focus
on
this
particular
topic
as
like
single
person
owning
that
part
of
the
specs,
the
structure
and
the
changes
and
like
documenting
that
and
reaching
to
the
team.
I
think
this
would
be
the
most
beneficial
why
we
kind
of
keep
away
these
smaller
items
concurrently
on,
let's
say
things
that
are
more
undefined
yet,
but
we'll
kind
of
reduce
the
risk
on
this
one.
One
major
items
that
I
kind
of
foresee
right
now.
C
That
makes
sense,
I
think,
yeah.
I
can
at
least
create
an
issue
for
that,
and
then
you
can
add
it
to
the
current
priorities,
which
is
just
say
like
this
is
de-risking
we're
trying
to
do
it
early
and
we
want
to
get
involvement
early
and
yeah.
Whoever
picks
that
up
will
collaborate
with
security
secure
to
figure
this
out.
C
Can
you
leave
an
inline
comment
or
something
with
just
the
thing
you've
seen
that
makes
you
go
okay?
I
know
this
is
a
big
problem
and
just
that
that
will
just
start
me
off
and
then
I
can
use
that
to
create
the
issue.
Talk
about
denormalization,
talk
about
different
options
and
then
I'll
find
the
right
people
to
communicate.
It
too.
B
C
C
B
This
is
one
of
the
examples
like
the
the
main
one,
but
there
are
other
ones
that
the
crosswinding
vulnerability
counts,
probably
to
find
a
project
as
well.
So
this
will
also
not
be
possible.
B
C
C
I'm
happy
with
that
as
a
an
action
here
to
split
things
up
but,
as
you
know,
there's
more
people
on
the
team
that
maybe
also
want
more
things
like
that
to
get
split
out
to
contribute
without
trying
to
push
to
this
branch.
B
So
I
would
kind
of
propose
that,
like
me
and
something
we
continue
like
for
a
few
more
days
like
I
don't
know
to
monday
tuesday,
get
this
poc
more
green
than
it
says
like
we
are
kind
of
don't
have
overlap
on
time
zones
as
much,
so
I
think
it
should
be
acceptable
and
then
like
we
on
the
next
meeting
on
monday
or
wednesday,
we
kind
of
decide
on,
let's
say
starting
to
chip
away
by
the
way
issues
out
of
the
big,
mr
and
work
on
this,
like
structural
thing
that
we
could
merge.
B
Then,
like
we
have
the
parier
which
is
joining
us,
I
think
we
should
invite
him
to
this
meeting.
I'm
not
sure.
B
Will
be
actually
working
with
us
day
by
day
on
the
database,
so
I
think
that
next
week
we're
gonna
have
more
like
also
like
things
on
the
database
side
that
needs
to
be
fixed
as.