►
From YouTube: 2021 06 30 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
Adam,
are
you
good
you
fine,
almost
ready
in
a
week
from
now,
I
will
have
also
as
ledger
so
oh
congrats.
B
So
yeah
I'm
ready
for
a
few
months
of
getting
back
together,
no
sleep.
Let's
see
so
yeah,
I'm
trying
to
wrap
up
things
now
so
that
yes-
and
hopefully
she
won't
come
earlier
because
you
know
I
need
a
molecular
copy
test
in
order
to
be
able
to
get
in
the
hospital.
B
B
Yet
in
greece
we
have-
and
I'm
going
to
take
my
get
my
second
shot
tomorrow,
but
because
it
won't
be
14
days
before
so
before
14
days
pass,
you
have
to
also
do
a
molecular
test
in
order
to
be
able
to
get
yeah
so
yeah
tomorrow.
My
second
episode
and
then
seven
days,
a
little
girl.
B
A
B
So
dylan
is
out
today.
Should
we
wait
for
one
more
minute
to
for
camille.
B
B
Sleepless
nights:
how
long
will
you
be
out
two
months?
I
will
be
two
months
and
I
will
be
out
until
school
start
so
because
now
with
I
have
my
old
one,
I
have
a
son.
He
is
five
years
old,
so
I
will
be.
I
will
have
to
take
care
of
him
until
school
starts
on
14th
of
september,
so
I
will
be
for
two
two
full
months
out.
B
C
B
B
C
B
C
C
A
Yeah,
does
anyone
know
how
to
answer
the
first
question.
A
C
C
C
A
D
Can
I
help?
Are
there
any
questions.
D
Okay,
I
I
have
a
high
level
question
for
regarding
this,
because.
D
I
thought
you
know
for
for
jio's
main
purpose,
which
is
replicating
the
the
current
main
posters
database,
which
is
uncharted
geo
just
relies
on
streaming
replication,
so
we
just
replicate
everything
that
is
on
the
database
server.
If
there
were
multiple
logical
databases,
we
would
do
the
same
thing.
D
So
if
we
have
two
database
servers
now,
one
managing
all
of
the
ci
stuff,
the
jio
support
here
essentially
means
have
another
thing:
streaming
replicate
to
a
secondary
site,
and
that
is,
I
think,
actually
you
know
not
so
different
from
what
is
happening
already
right.
I
think
the
I'm
sure
there's
more
more
difficulty,
the
geo
tracking
database.
I
don't
know
what
the
implications
are
there,
because
we
would
have
to
track
events
from
two
different
databases.
D
I
anticipate
that
that
is
probably
the
the
bigger
piece
of
work
right
to
make
sure
that
we
have
those
events
as
well,
but
that's
sort
of
my
high
level
view.
B
Yeah
and
the
assumptions
that
geocode
has
about
where
tables
are
so
at
the
moment.
I
assume
that
and
as
it
is
logical,
the
geotracking
database
and
the
geo
events
and
everything
related
to
jio
are
the
code
that
screams
that
they
will
find
everything
everywhere.
So
there
is,
I
think
that
the
ci
job
artifacts
are
tracked,
so
the
code
assumes
that
cig
of
artifacts
will
be
found
on
the
main
database.
So
I
I
will
assume
that
there
is.
There
will
be
a
requirement
for
the
geo
team
to
add
a
significant
amount
of
updates.
B
D
Yeah,
so
I
think
yeah,
so
my
my
suggestion
here
would
be
to
just
connect
with
douglas,
but
douglas
is
going
to
be
on
parent
leave
relatively
soon
as
well,
so,
maybe
nick
to
understand
what
needs
to
be
done.
I
see
camille
said
we
are
doing
only
essential
things
for
self-managed
geo,
not
sure
I
think
the
important
thing
here
to
realize
is
that
I
think
80
percent
of
our
largest
customers
run
geo,
and
so
the
people
that
would
maybe
even
consider
thinking
about
sharding
are
also
using
geo
right.
C
Yeah
annoyed
about
yes,
but
like,
like
my
comment,
refers
to
like
what
we
are
doing
now.
It
doesn't
happen
to
what
we
have
to
do
in
the
future
and
like
in
the
future.
The
like
the,
I
think,
general.
I
think
it's
like
we
want
to
ensure
that,
like
self-managed
run
as
closely
as
possible
to
how
we
run
github.com,
this
is
like
a
goal
just
right
now
we
we
may
like
dismiss
some
of
these
problems
by
choosing,
let's
say
much
less
frequent
path
and
about
the
geo.
C
Have
probably
been
the
closest
resemblers,
how
we
want
like
this
to
work
on
right
now,
maybe
it's
not
the
end
story,
but
how
you
want
this
to
work
right
now,
so
this
could
be.
I
guess
my
suggestion
about
trying
to
engage
yeah.
D
D
C
So,
like
I
guess
like
the
thing
is
like
will
not
be
ready
yet
to
accept
changes
on
master,
but
we
will
be
hopefully
ready
to
ask
them
to
assess
what
needs
to
be
changed
and
maybe
start
you
seeing
these
changes
with
the
anticipation
that
they
will
contribute
these
strangers
once
we
are
ready.
C
Let's,
let's
read
my
perspective
because,
like
I
think
there
is
like
the
like
pretty
particular
order
of
actions
that
we
need
to
do
on
decomposing,
poc
and
geo
is
pretty
far
in
this
feast
view
is
pretty.
D
A
A
Okay,
guess
that's
point
one
function
point
two
funchan
is
anyone
in
the
working
group
meeting
that
can
expand
on
that.
C
D
C
I
I
was
there
is
still
like
some
misalignment
on
like
what
we
are
doing
because,
like
it
did
pop
up
that,
like
we
do
normalization
of
the
match,
request
data
with
the
uric
work
kind
of
dropping
500
gigs
of
data.
But
it
asks
us
if,
if
whatever
yorick
is
doing
on
a
prevent
sharding
of
the
data
later-
and
our
answer
is
no
but
the
there
is
like
some.
C
I
guess
this
sentence
about
the
sharding
pop-up
in
the
class.
In
the
context
of
the
composition
that
we
are
doing
kind
of
raise
some
questions
on
like
ensuring
that
seats
and
like
we
are
all
aligned
to
know
exactly
what
we
are
doing,
because
it
kind
of
writes
the
concern
that
whether
city
is
still
thinking
that
we
are
actually
right
now
doing
sharding.
C
Instead,
the
composition
and
like
whatever
we
deliver,
is
actually
like
the
sharding
solution,
which
is
not
so
as
for
that
piece
of
the
deep
bloating
and
my
sequence.
I
think
it
got
clarified
in
the
video
database
capability
working
group
tunnel
that
in
any
model
it's
actually
like
having
table.
That
is
like
one
gig
of
data
instead
of
500
gig
of
data
is
simply
better,
even
if
it's
normalized
and
like
it
doesn't
likes
it.
It
doesn't
really
like
cause
like
a
harm
into
very,
very
exciting
solution.
C
Later,
that's
really
like
I,
I
think,
like
the
summary
from
eurek
and
craig
that
got
delivered
to
to
eric,
but
we
actually
now
also
actively
working
on
ensuring
that
this
is
clear
about
what
is
being
done
and
what
is
like
the
benefits
and
how
it
affects
the
future
steps,
because
starting
is
not
really
like
our
focus
right
now.
It
may
become
like
in
one
year
from
now,
but
not
really.
At
this
moment
we
are
now
doing
the
composition,
so
this
was
something
that
kind
of
raised
this
question
like
like.
C
Are
we
actually
sure
that,
like
all
levels,
don't
understand
what
we
are
doing.
B
I
agree
with
the
committee
and
I
think
that
our
top
priority,
together
with
the
composition,
should
be
for
everything
else
to
to
bring
everything
below
100
gigabytes
or
even
lower.
So
once
we
have
all
tables,
small
and
agile,
and
we
are
able
to
do
migrations
and
we're
able
to
to
everything
will
be
way
better.
And
then
we
can
start
thinking
if
we
need
charge
for
those
things
in
the.
C
What
we
kind
of
investigated
initially
for
the
sharing
solutions,
kind
of
imply,
like
only
like,
like
a
very
specific
ways,
how
we
could
do
it
for
the
application
that
we
are
doing,
because
it
was
big,
it
was
holistic.
It's
not
something
that
we
can
like
disconnect
and
like
the
our
perspective
on
the
siding,
is
actually
machine.
When
we
start
looking
on
the
smaller
subset,
we
have
actually
like
much
more
different
ways
might
be
more
efficient,
easier
to
execute.
C
If
we
look,
for
example,
at
the
compositing,
only
ci
tables
charging
the
ci
table,
so
I
I'm
kind
of
like
what
I
saw
that
crack
and
I
started
doing
is
like
they.
They
started
like
describing
exactly
how
it
may
look
after
the
composition,
but
in
the
narrow
it's
like
that,
we
actually
have
the
more
ways
and
more
iterative
and
much
easier
to
execute
and
much
more
stable
after
the
composition.
C
But
I
think
it's
something
that
kind
of
pop
as
a
potential
unclear
if
it's
actually
clear
that
this
is
something
that
opened
us
like
more
power,
but
it
also
means
that
we
are
not
delivering
starting
right.
Now
we
are
verifying
the
composition.
This
is
really
our
focus,
but
these
are
the
paths
moving
forward
after
we
do
it.
That's
that's
the
kind
of
like.
B
C
B
Table
as
long
as
we
do
the
composition
with
respect
to
sharding,
it
will
go
together
with
the
other
table
so
with
respect
to
vertical
starting.
This
is
not
a
problem
with
respect
to
horizontal.
There
is
a
discussion,
but
we
have
a
agreed
that
this
is
a
future
step
either
way,
and
we
will
have
to
think
about
yeah.
D
I
think
I
understood
this,
so
I
I
do
agree
with
what
camille
said.
We
need
to
be
clear
on
what
we're
doing.
I
think
the
question
is
also
if
we
were
at
some
point
in
the
future
to
do
horizontal
application
double
shrinking.
Would
this
change
make
that
impossible,
and
I
think
the
answer
to
this
is
no,
and
so
I
think
this
is
this
should
be
also
enough,
because
even
if
we
were
to
go
down
that
future
path,
we
would
still
be
able
to
figure
it
out.
B
And
yeah
we
have
a
relational
database.
We
cannot
remove
all
normalization,
so
it
will
be
great
if
we
have
the
at
fully
normalized
database
for
sure
it
will
be
easier
at
some
point
to
do
horizontal
starting,
but
because
we
have
a
relationship
and
we
have
to
live
with
a
relational
database.
We
have
to
live
with
normalization.
There
is
no
way
we,
we
cannot
do
normalization
so.
C
I'm
kind
of
thinking
that,
like
really
like
in
the
whether
like
how
you
do
starting,
you
should
be
looking
at
the
cardinality
of
the
data
set.
Just
some
dataset
have
very
low
cardinality
and
right
now,
like
doing
let's
say,
replicating
this
data
set
many
times
with
like
index
for
the
particular
let's
say:
project
id.
C
It's
not
really
like,
sometimes
efficient,
and
I
think
like
what
york
is
doing
with
like
with
this
normalization
of
the
image
is
actually
like.
The
data
set
that
has
that
doesn't
have
very
high
cardinality
and
we
not
really
have
high
cardinality
and
like
it's
something
that
is
pretty
great
to
the
partition
as
well.
C
So
I
I'm
kind
of
like
thinking
that,
like
like,
when
you're
deciding
you
need
to
look
at
the
the
type
of
the
data
that
you
are
starting.
Just
some
type
of
the
data
have
very
high
cardinality,
very,
very
random
access
pattern
like
like
a
lot
of,
maybe
like
something
that
simply
I
don't
know
timely
case
or
like
it's
very
specific
for
the
project,
and
this
is
where
I
like
to
make
sense.
C
But,
like
I
mean
in
this
particular
case,
you
think
what
we
are
doing
is
actually
like
the
the
same
thing
to
do,
because
we
are
very
rarely
going
to
after
this
table.
You're
gonna
be
mostly
reading
from
this
table,
and
now,
if
you
follow
the
different
pattern
of
the
merch,
equals
push
you're
actually
like
each
time.
You're
gonna,
be
writing
a
lot
of
data
on
like
creating
this
duplication.
So
on
that
sense,
I
I
think
like
it
doesn't
like
break
any
other
future
work.
C
D
B
So
we
may
have
to
do
it
at
some
point
so,
but
this
is
not
the
way,
so
we
have
seen
also
what
the
tesla
does
and
what
cytos
does
that
the
important
part
and
what
they
care
about
a
lot
is
not
only
starting
horizontally
and
moving
things
around
in
servers
is
also
all
those
small
entities
like
this
specific
one.
That
yorick
has
added
having
the
infrastructure
to
replicate
that
entity
or
in.
B
And
keep
them
synced
in
sync.
That
would
be
a
part
of
our
solution
either
way,
either
by
using
one
of
those
tools
or
building
it
on
our
own.
So
all
those
small
support
entities
like
the
one
that
keeps
track
of
the
emails
and
names
of
authors
and
committers.
B
D
D
Okay,
the
next
question
from
june
is:
can
we
fan
out
work
to
other
teams
already
and
give
them
an
early
heads
up?
My
question
was:
do
we
already
have
enough
information
for
this.
D
D
Omnibus
db,
right,
that's
the
thing
we
know
about
geo
and
supporting
this.
C
A
C
Broken,
I
think,
like
what
you
adam
started.
Working
active
record
base
is
something
that
we
need
to
also
look
at
and
how
it's
being
used.
We
just
like
all
these
robocop
rules
and,
like
I
don't
know
like
moving
away
from
this
pattern
because,
at
least
in
the
plc
I
know
that
I
have
to
fix
a
bunch
of
the
places
where
you
use
dot
connection
on
active
record
base.
C
But
the
truth
is
like
there
is
like
a
lot
of
these
small
things
to
like
to
figure
out
how
to
do,
and
maybe
maybe
what
makes
sense
right
now
is
like.
I.
I
think
that,
like
one
thing
that
is
kind
of
clear
to
me
that
and
I'm
happy
of
that,
because
that
we
should
maybe
that
we
should
definitely
create
a
github
ci
schema,
and
this
is
something
that
I
think
that
we
kind
of
get
to
the
consensus
is
something
that
we
need
and
it's
going
to
help
us
a
lot.
C
C
C
A
Shall
we
move
on
to
the
next
question
number
four,
so
I
understand
camille
has
said,
there's
a
lot
of
small
questions,
but
for
me
there's
two
big
questions
that
has
been
asked.
This
is
swelling
around
from
the
discussion
from
andreas
and
etc.
A
A
C
C
I
I
think,
like
I
kind
of
like
see
the
andrea's
point
right
now,
it
may
be
simpler
to
do
like
the
joint
schema,
but
I
I
kind
of
feel
that,
like
long
time,
it
creates
a
cause
because,
like
you
kind
of
then
populate
a
lot
of
tables
that
you
are
not
using
and,
for
example,
one
of
the
things
that
I'm
kind
of
seeing
the
problem
is
like
like,
if
you
have
two
databases
and
you're
gonna-
have
to
run
some
migrations
like
in
both
of
them
and,
for
example,
one
of
the
problems
that
I'm
seeing
like.
C
So
it
kind
of
creates
your
accounts
that
you
don't
know
really
that
if
you
are
configuring
this
database,
you
are
not
really
sure
if
you
need
all
of
these
things
out
of
the
public.
So
the
tricky
part
in
this
model
is
like
that.
It
actually
has
his
drawbacks,
because
you're
kind
of
using
github
ci,
mostly
on
another
database
but
you're,
also
kind
of
using
editor
of
the
public
and-
and
it's
maybe
sometimes
hard
to
discover
that
you're
using
parts
of
the
public
and
it's
your
like
database
is
pretty
inflated
on
the
schema.
C
C
But
it
kind
of
gives
me
like
another
perspective.
If
this
is
a
little
more
complex
and
our
public
is
a
sinkhole
today,
and
we
know
that
some
of
the
tables
needs
to
be
used.
Let's
say
in
the
main
and
ci
database,
and
we
know
about
at
least
of
one
schema
migrations
and
maybe
another
one
being
background
migrations.
C
Then
I
would
simply
propose
if
this
is
the
model
that
we
move
them,
that
we
create
third
schema,
which
is
cert
and
we
move.
These
tables
in
this
shared
schema
to
clearly
anticipate
that
public
is
only
using
the
main
context,
but
shared
is
something
that
can
that
is
used
by
the
each
of
these
databases
individually,
because,
like
schema
migrations,
you
keep
versions
in
the
database
and
it's
always
the
in
the
context
of
the
given
database.
It's
not
that,
like
you,
are
inserting
timestamps
when
you're
running
migrations
on
the
ci
into
a
main
database
background.
C
Migrations
is
something
that
we
need
to
kind
of
work
on
and
figure
out.
What
is
the
best
model
because
currently
background
migrations,
they
are
being
tracked
only
on
the
main.
The
question
is
like:
should
they
be
track
on
the
main
and
kind
of
create
a
situation
that,
like
you're
kind
of
executing,
let's
say
a
split
brainstorm
like
situation
that,
like
you
track?
Let's
say:
migration
on
the
ch
of
artifact,
which
is
living
in
another
database
effectively.
C
I'm
kind
of
thinking
that
maybe
in
these
models,
better
simply
like
to
keep
the
locality
of
the
data
and
background
migrations,
if
you're
running
in
the
context
of
that
database,
the
same
as
schema
migrations,
you're,
not
gonna,
run
other
timestamps
of
them.
Ci
database
into
main
database,
you
kind
of
keep
the
locality,
but
this
is
something
really
like
to
figure
out
how
to
tackle.
C
For
example,
you
cannot
really
like
configure
today
in
a
very
predictable
way,
or
maybe
you
can-
and
maybe
this
is
like
the
valley
thing,
but
I
don't
know
but
like
there
is
like
different
problems
associated
if
you
configure
two
different
connections
having
migrations
that
point
to
the
same
logical
database
but
different
schemas,
then
the
question
is
like
a
schema
migration
table,
your
search
path
being
used
and
how
actually
migrations
are
being
executed
because
now
like
how
it
works.
Today,
you
kind
of
proceed
main
and
then
you
proceed
ci
so
effectively.
C
If
you
have
the
third
migration
folder
you're,
going
to
execute
all
migration
from
the
main
and
you're
not
going
to
execute
any
migrations
on
the
ci
and
then
like
the
question
is
like
how
you
actually
motor
migrations
to
kind
of
indicate
the
context
in
the
which
they
are
should
be
running.
In
probably,
I
don't
know
in
this
model
you
kind
of
need
to
like
define
as
part
of
the
migration,
what
schema
you're
modifying
to
like
limit
visibility.
C
But
this
is,
I,
I
guess,
like
the
problem,
to
figure
out
like
how
to
how
to
implement,
invest
so
and
now
like.
If
you,
if
you
have
two
separate
folders
like
two
separate
logical
databases,
kind
of
some
of
these
problems
go
away,
but
actually
probably
we're
gonna
start
with
like
the
third
solution,
which
is
like
we're.
C
But
I
I
think
it's
still
like
not
ideal,
because
it
has
its
own
set
of
the
drawbacks
and
how
you
manage
structure
sql.
It's
like
partially
related
to
that,
because
it
also
implies
like
the
visibility
and
like
what
data
are
being
shared
and
even,
if
you
know
like
what
is
certain
like
what
is
required
in
these
two
different
contexts
and
like
our
cleanup
later
as
well,
because
if
you
are
not
sharing,
you
are
simply
know
that
you
can
drop
public
schema
and
be
done
with
that.
C
But
now,
if
you
use
parts
of
the
public,
it's
actually
becoming
a
little
more
complex.
I
like
to
do
so.
I
I
think
this
question
is
like
we
cannot
really
yet
answer,
at
least
from
my
perspective,
how
to
do
it?
C
I
think,
need
to
like
work
on
the
like
the
problems
on
defining
like
how
you
want
to
configure
how
what
are
the
drawbacks,
how
the
migrations
gonna
be
around
in
this
different
scenario,
but
I'm
kind
of
thinking
that
doing
certain
schema,
maybe
like
this
arrival
at
that
moment,
because
it
may
be
simpler,
but
we
need
kind
of
probably
figure
out
a
way
to
ensure
that
you
are
not
dependent
on
public
and
a
table
of
the
public.
C
If
you
are
running
another
logical
database
with
the
ci,
so
kind
of
kind
of
not
even
like
doing
two
schemas,
maybe
even
doing
free
schemes
to
clearly
indicate
what
is
truly
served
between
that
so,
but
I
I'm
kind
of
now
trying
like
to
to
like
to
to
model
schemas
approach
on
the
poc
and
our
trees.
C
So
it
kind
of
like
improves
visibility
on
constructs
that
are
allowed
or
forbidden
in
that
model
like
usage
of
the
schema,
because
it's
3d,
you
can
move
whatever
tables
you
want
to,
and
you
kind
of
prevent
like
cross
schema
joins
sorry
for
my
lengthy
answer.
I'm
not
sure
if
it
doesn't
answer
does
answer
any
of
your
questions.
B
I
want
to
add
something
on
top
of
what
kami
says
and
this
what
we
were
discussing
about
the
problem
with,
for
example,
schema
versions
and
some
other
utility
tables
that
reside
on
the
public
schema.
C
B
We
will
have
to
figure
out
what
we
are
going
to
do
with
those
tables.
So
it's
a
it's
schema
versions.
There
are
a
few
utility
tables
that
we
have
for
tracking
bats
background,
migrations,
background,
migrations
and
all
those
that
we
may
want
to
have
them
somewhere.
So
maybe
the
problem
there
is
figuring
out
what
we
are
going
to
do
with
those
tables.
B
I
think
that
if
we
figure
out
that
and
how
to
be
explicit
in
migrations
about
schema,
so
that
when
we
are
talking
about
the
table
to
be
explicit,
that
this
table
to
also
provide
a
schema
for
the
table,
always
if
we
are
explicit
that
on
that
front
and
the
other
one,
I
think
that
an
address
proposal
does
not
have
a
lot
of
other.
B
But
yeah
if
we
solve
those
big
problems
that
you
just
mentioned,
but
if
we
solve
those
big
problems
address
proposal,
it's
like
we
can
have
the
duplicate
schema,
but
we
can
easily
drop
the
schema
that
you
know
the
what
we
call
now
main
all
the
other
cables.
It's
like
like
that,
it's
very
easy
to
drop
it
or
move
it
out
of
the
way.
C
Yes,
yes,
like
I,
I
fully
agree
if
you
like
that,
what
isn't
just
proposing
like,
doesn't
it
it's
like?
It
has
its
own
other
problems
that
need
to
be
worked
on,
but
also
it's
like
the
the
problem
is
different
like
it's,
not
something
that
you
can
do
like
you
know
like
one
week,
it's
like
rather
a
process
that
you
need
to
kind
of
follow
and
even
like
us
leveraging
schema
search
path
is
actually
something
that
we
need
to
take
iteratively
to
github.com.
C
So
I
I
think,
like
the
biggest
my
contention
point
with
the
andreas
is
like
was
that
he
asked
like
to
do
all
the
schema
proposal
right
now,
which
actually
would
take
us
like
months
to
do,
and
I
don't
know
whatever
time
I
I
I
like
like,
like
we
have
a
lot
of
our
like
extensions
to
to
race
that,
for
example,
I'm
not
sure
like
if
the
schema
search
works,
always
in
all
cases,
so
we
have
to
make
sure
that
yeah,
so
so.
B
C
You
need
to
kind
of
roll
out
that
interrupt
and
kind
of
requires
modifying
a
lot
of
components
and
like
like
we
can.
We
can
follow
the
proposal,
but
it
just
takes
time
and
like,
like
the
main
convention
point
for
me,
was
like
what
we
have
now
is
like
good
enough
to
ask
iterate
on
that,
because,
like
it
kind
of
give
us
better
perspective,
how
these
things
should
be
modeled
and
kind
of
unblocks.
C
It's
something
that,
like
us,
merging
that
actually
allowed
us
to
now
get
tonk,
mr
on
the
github
development
kit
and
my
on
the
gck
and,
like
we
kind
of
started
to
actually
to
move
forward
with
that.
So
I
I
think,
like
my
my
whole
sentiment
is
like.
C
Each
of
them
is
like
to
be
like
iterated,
and
we
need
to
kind
of
like
do
it,
adding
small
pieces
step
by
step
to
the
production,
to
see
that
we
don't
break
because,
like
schemas
here,
search
buff
like
for
me
like
we
can
create
schema,
we
need
to
update
many
places
to
with
database
wiremap
to
leverage
the
schema
search
path.
We
need
to
actually
validate
that.
Actually,
this
schema
search
box
is
properly
used
in
all
of
these
cases
to
ensure
that
it's
actually
not
broken.
C
I
I
I
have
limited
trust
in
our
test
suit,
yeah
that
it's
actually
like
doing
the
right
thing.
So
this
alone
is
like
probably
one
or
two
weeks
to
do
to
like
to
like
go
through
all
the
rollouts
and
now
like
changing
how
we
manage
our
migration
is
like
switching
the
config
already.
B
Can
I
say
something
here,
so
this
is
we're
talking
about
two
or
three
weeks
in
a
roadmap
that
will
take
us
a
year
or
two
years
and
what
I'm
seeing
here
and
why
I
really
like
address
proposal
after
I
understood
it
and
discussed
it
with
him,
is
that
this
also
gives
us
a
pretty
nice
unified
way
to
all
to
treat
omnibus
single
database
installations
and
multi-database
installations
at
the
same
time
without
it
without
too
many
changes
after
we
make
sure
what
we
are
discussing
so
for
sure
there
there
is
this
overhead
in
the
beginning,
but
then
it
seems
to
me
like
a
more
unified
approach
that
it
would.
C
Yes,
but
this
this
is
one
of
the
tracks
like
like
magnetic
of
the
schema
moving
tables
is
one
of
the
tracks.
You
actually
have
five
different
concurrent
tracks
that
are
happening
and
now,
like
you,
delaying
that
one
truck
by
a
few
weeks,
you're
actually
delaying
all
other
tracks
as
well,
so
it
has
the
cascading
effect,
and
now,
if
you
can
do
make
something
simpler,
that
just
works
now
and
iterate
on
that
not
causing,
because
we
are
not
using
that
yet
we
are
not
running
out
of
the
production.
C
It
has
basically
like
the
zero,
like
cost
associated
with
maintaining
that.
B
That's
the
problem,
that's
the
problem,
in
my
opinion,
with
setting,
so
we
may
end
up
locking
ourselves
in
in
a
solution
that
is
suboptimal
because
we
we
are
setting
deadlines
and
it's
great
that
we're
setting
deadlines
at
the
three
months
or
four
months
deadlines,
but
we
have
to.
I
think
that
we
should
take
the
time
to
be
sure
that
we're
following
the
right
approach,
because
after
two
years,
not
after
two
months,
we
won't
be
able
to
easily
go
back.
We
can
always
go
back,
but
you
know
what
I'm
saying
here.
B
So
what
I'm
gonna
say
is:
let's
not
reject
the
proposal
that
may
be
the
best
proposal
because
it
will
delay
us
by
one
month.
That's
my
opinion.
C
Yes,
but
like
none
of
the
proposal
is
rejected,
it's
more
like
we
have
a
lot
of
uncertainty
and
a
lot
of
things
to
discover
to
figure
out
what
is
the
best
proposal.
There
is
no
clear
best
proposal.
If
you
would
clear
great
proposal,
we
would
actually
have
planned
everything
ahead
of
the
time,
but
yeah
we
are
dealing
with
a
lot
of
uncertainty.
How
to
do
it,
so
I
agree
so
like
like
even
in
the
I'm
just
proposal,
even
in
like
what
we
are
doing
right
now.
C
There
is
like
a
lot
of
problems
associated
with
that.
There
is
like
not
a
golden
path.
That's
that's,
really
the
tricky
and
the
the
one
thing
that
you
can
do
with
that
is
like
those
small
steps
figure
out
like
fix
that
see.
If
it's
actually
moving
you
in
the
right
way
direction.
If
it's
not
like
just
revert
and
do
it
do
it
better,
and
this
is
exactly
what
I'm
thinking
what
and
we
are
doing
like
we
are
iterating.
We
are
finding
this
also.
D
If
we
are
doing
what
khamir
proposes,
does
this
rule
out
doing
what
andreas
proposals
proposes
it
does
not
right
so
is
it
is?
It
is
the
risk
more
that
we
we
are
going
to
pursue
a
slightly
different
path
now
and
then,
due
to
time
pressure,
we
will
no
longer
be
able
to
do.
The
other
thing
that
we
know
has
maybe
some
longer
term
effects
is
that
the
risk
here.
B
B
Maybe
maybe
not
this
is,
I
don't
know
duncan
camille
can
talk
about
that
more.
B
C
So
like
now,
like
going
between
one
to
b,
when
you
have
all
the
other
things
in
place,
like
the
let's
say,
support
for
the
schema.
It's
probably
one
week
worth
of
the
work
on
changing
how
you
configure
your
configuration
to
what
migrations
to
run
and
what
file
to
use.
C
So
the
the
part
is
really
like
associated
with
all
of
these
actuary
blocks
that
you
need
to
execute
for
this
proposal
to
work
right
now
that
takes
significantly
longer
than
actual
functional
term
that
you
need
to
perform
later.
I'm
kind
of
here
in
particular
referring
to
leverage
of
the
schemas
and
like
ensuring
that
this
I
actually
works
properly.
C
This
is
a
substantial
change
to
the
application
behavior,
and
we
cannot
really
like
push
configs
and
ensure
that
things
gonna
work
after
we
move
like
a
single
table,
I'm
kind
of
more
anticipated
that,
like
we
need
to
do
it
like
step
by
step
to
ensure
that
nothing
breaks
and
like
yeah,
even
like
mentioned,
like
on
some
of
the
meetings
recently,
that
we
have
customers
search,
managing
their
schemas.
C
C
A
B
I
think
that
we
will
either
way
have
to
to
deal
with
those
restrictions
and
be
more.
You
know
opinionated
about
the
fact
that
we
we
need
more,
a
better,
a
higher
level
role,
more
rights
on
the
database,
the
I
don't.
I
cannot
see
a
way
forward
without
that,
but
this
is
a
small
thing.
A
Structure:
question
because
it
is
for
development
is
much
simpler
to
have
a
smaller
structure.
We
don't,
I
don't
have
to
deal
with
potentially
don't
have
to
deal
with
migrations
data
migrations
just
affecting
the
ci
database.
That's
what's
one
thing
as
well
and
I
think
it's
it's
still
reversible
at
this
point,
because
everything
is
doing
production
everything's
in
development.
Sorry,
as
janice
was
saying,
we
can
just
deeply
reset
the
local
database
and
switch
it
back
to
the
other
one.
A
But
I
don't
know
because
andreas
explicitly
mentions
this
that
go
as
a
goal
to
say
that
we
want
to
keep
exactly
the
same
database
schema
between
main
and
ci,
but
I
don't
think
that's
go
so
that's
not
a
go.
Then
I
don't
know
whether
that
affects
the
whole
proposal
or
not.
I
doesn't
look
like
it,
but
that's
why
I
really
wanted
to
make
clear
that
this
is
not
what
we
want
in
the
future
anyway.
D
So
so
I
have
two
two
or
three
main
concerns
right
and
I
think,
like
these
are
great
discussions
to
have
it's
like
my
one
concern
that
I
have
is
we're
going
to
lock
ourselves
in
because
of
constraints
and
we're
going
to
not
be
able
to
go
back
right.
It
sounds
to
me
as
if
that
is
not
a
huge
risk
at
the
moment
because
of
the
state
where
we
are,
but
we
need
to
be.
Mindful
of
that.
Is
that
correct.
D
B
With
more
confidence,
it's
not
like
differently
and
as
camille
said,
that
the
tongue
and
everyone
it's
not
like,
we
know
that
this
is
about
the
other.
One
would
not
be,
but
we
will
have
the
time
so,
for
example,
we
we
will
have
the
time
to
also
go
and
do
a
proof
of
concepts
of
what
andreas
has
is
proposing,
and
then
we
will
not
worry
that
much
of
blocking
other
things
in
my
opinion,
but
yeah.
Maybe
we
can
also
do
that
either
way.
B
B
So
can
I
propose
something:
should
we
ask
adrias
to
join
us
in
our
next
call
so
that
he
can
also
discuss
with
the
team
his
proposal,
because
I
can
see
that
there
is
a
large
discussion
here
about
this
yeah.
D
B
D
There
are
different
things,
so
I
my
understanding
is
that
the
the
saturation
report
on
the
database
indicates
that
we
will
not
have
any
problems
within
the
next
nine
months.
It
does
not
mean
that,
after
nine
months,
in
my
view,
we
will
have
will
immediately
have
a
problem.
It
just
gives
us
nine
months
in
which
we
believe
with
relatively
high
confidence,
that
there
won't
be
a
problem.
D
D
That's
that
I
need
to
hop.
So
is
there
anything
else
you
need
from
me
right
now.