►
From YouTube: 2020 09 29 Database Team Weekly
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
All
right
welcome
to
the
database
team
weekly
meeting
jump
right
into
it,
so
I
wanted
unless
anybody
else
had
any
topics.
Someone
talked
about.
First,
I
was
gonna
run
through
the
issues
and
look
at
deliverable
labels
all
right.
A
So
we
have
30
issues
overall
in
this
milestone
and
I
filtered
out
the
ones
that
already
had
deliverables
on
them.
We
can
go
back
and
review
them
again
if
it
makes
sense,
but
I
want
to
run
through
the
ones
that
did
not
have
deliverable.
It
looks
like
andreas.
You
added
a
couple
in
the
last
couple
hours,
so
we'll
just
go
top
to
bottom
there
on
any
particular
order.
I
guess
there
might
create
a
date
order.
So
do
you
think
this
one
will
be
done.
This
milestone.
B
Yeah,
okay
yeah
those
should
be
fixed
in
a
small
zone
insert
this
is
stupid.
I
mean
I've
been
I've.
I've
set
a
statement
timeout
in
gdk,
and
I
I
was
a
bit
naive
and
thinking
that
the
15
seconds
will
work
everywhere
and
it
doesn't,
and
the
last
one
of
the
things
that
popped
up
was
the
most
inserted
seating
that
yeah
just
doesn't.
It
doesn't
work?
Obviously,
so
I
yeah,
I
gotta
fix
that
same
cycles.
A
A
What
about
this
one,
it's
not
assigned
to
anybody!
It's
created
by.
B
Jose
there
is
another
issue
that
should
go
in
before
that.
I
think
so.
We
have
two
issues
there.
One
is
implementing
the
rubric
to
prevent
new
tables
without
the
primary
key
and
then
the
second
one
is
to
fix
the
existing
ones.
B
A
So
it
sounds
like
this:
one
has
a
dependency
on
the
other
one.
Do
we
want
to
mark
this
one
as
deliverable
as
well
or
not
since
there's
a
dependency
blocking.
A
B
Yeah,
I
put
it
on
the
site
for
the
remixing,
but
if
I
managed
to
get
this
done
this
week,
then
I'll
pick
that
up
again.
Okay,
it's
also
my
okay.
So
I
should
pick
it
up.
A
Probably
all
right,
let's
see,
connect
timeout
applied
twice.
A
B
It's
not
terribly
important,
it's
just
a
funny
pattern
that
we
saw
you
might
want
to
prevent
that.
A
Okay,
materialize
issue:
another
stretch.
B
B
C
A
A
We've
identified
the
common
themes
right
like
not
having
production
like
data,
but
we're
working
through
a
solution.
Now
we're
throwing
out
ideas
for
solutions
so
not
a
deliverable.
This
one
was
created
by
grant
and
I
don't
think
anybody's
looked
at
this
one,
so
we'll
just
leave
it
as
it
is.
Let's
see,
proposal
for
events
partitioning.
C
A
That
document
design
decision
validate
gitlab.com
database
schema
you're
working
on
that
now,
pat
right.
A
A
And
so
I
want
to
quickly
recap
the
vertical
mr
discussion.
Thanks
for
everybody's
feedback,
there
are
a
couple
good
sentences
and
summaries
in
there.
I
think
it
was
andreas
said
we
want
to
see
the
database
change
along
with
the
back
end
code.
That
makes
use
of
it
and
then
andre
spelled
out
an
even
more
detailed
summary
here.
A
Basically,
my
takeaway
from
that
is
the
the
mr
has
changed
quite
a
bit
at
the
beginning.
It
was
fairly
prescriptive,
saying
you
know
it
must
be
a
vertical,
mr
instead
of
horizontal
slicing,
but
now
it
has
backed
off
the
strong
wording
and
it's
basically
saying
ensure
that
all
context
is
included,
and
I
think
that's
what
you
all
are
saying
in
your
feedback
right,
make
sure
it's
not
horizontal
sliced
and
if
it
requires
back-end
code,
then
make
sure
that's
included
with
the
mr.
A
A
A
And
then
I
don't
know
if
anybody's
had
time
to
take
a
look
at
it.
Nick
gave
his
feedback
on
what
we've
been
talking
about
for
testing
migrations.
He
just
posted
a
couple
hours
ago.
So
take
a
look.
We
can
continue
the
conversation
there
haunted
events
like
I
said
they
have
some,
mrs.
There
were
updates
as
of
about
15
minutes
ago,
so
they're
still
working
on
the
ux,
so
we
can
switch
it
over
and
then
I'm
not
sure
I
think
it's
andreas.
Did
you
put
these
fyi
topics
in.
B
Yeah,
we
don't
have
to
talk
about
them.
If
we,
you
know,
I
just
wanted
to
mention
those.
I
found
those
interesting
conversations
about
like
how
to
implement
the
retention
strategy
using
partitions
and
also
somebody
was
asking
about
materialized
views.
You
can
use
them
and
just
wanted
to
drop
those
things.
A
A
C
B
D
Yeah,
I
want
to
wrap
up
the
documentation
for
the
partitioning
and
the
other
is
for
the
schema
validation.
I
think
you
know
identified
what
the
differences
are.
I
think
like
to,
have
you
know
strategy
and
how
we're
gonna
fix
each
of
those
various
types
of
differences,
so
I
can
start
implementing.
A
So
a
question
on
one
of
the
issues
I
should
have
left
it
open.
The
data
dictionary
plans
that
we
have
in
the
future
we
talked
about.
A
B
C
B
One
is
to
say
like
well,
please
comment
on
columns
and
tables
the
other
sort
of
idea
that
we
had
was
that
we
could
use
that
free
text.
B
Those
three
text
comments
and
put
some
more
structured
data
in
there
like,
for
example,
we
discussed
about
attributing
your
background
group
to
or
sort
of
indicating
who
owns
the
the
table,
and
that
would
be
a
more
more
structured
way
of
providing
the
documentation.
You
can
put
this
still
into
the
comment,
but
it
sort
of
needs
to
need
some
formats
of
instruction,
and
we
haven't
really
discussed
this
yet.
I
think.
B
Yeah,
that's
kind
of
the
question
also
for
container
registry.
There
is
one
team
that
owns
full
service,
which
is
really
good,
so
it's
pretty
clear
who
who
owns
stuff
so
maybe
that's
not
even
needed.
A
B
There
is
only
one
team
that
owns
that,
so
maybe
the
important
part
is
that
they
they
had
their
intentions.
How
to
use
those
tables
describe
that
we
can
always
use
a
different.
A
Yeah,
I
know
the
data
team
was
interested
in
getting
some
kind
of
data
dictionary
from
container
registry
since
it's
a
new
database
and
they
wanted
to
know
how
to
best
import
the
statistics
so
that
they
could
measure
it
while
they
import
it.
So
that's
the
only
reason
I
was
thinking
container
industry
because
it's
new
they're
still
working
on
the
schema
now
and
this
might
be
something
they
can
easily
get
in.
A
But
it
sounds
like
there's
still
some
question
on.
Is
this
the
right
structure
we
have
now
or
were
you
saying
earlier?
Let's
just
go
with
the
structure
we
have.
We
can
always
change
it
later,
since
this
is
an
isolated.
B
It
would
kind
of
be
interesting
to
if
there
is
any
more
sort
of
structure
that
we
can
find
or
need
to
find,
and
I
I
I
haven't
seen
enough
from
the
data
team
what
they
are
actually
expecting
to
get
so
is
it
just
like?
I
would
just
see
free
free
text,
comments
from
developers
on
tables
and
columns.
B
That's
even
just
comments,
that's
a
no-brainer
in
that
sense,
but
if
they
want
to
have
more
information
or
more
structured
information
on
that,
I
think
we
would
have
to
discuss
a
little
bit
more
in
more
detail.
B
C
One
discussion
started
because
the
data
team
tries
to
load
data
to
snowflake
and
create
reports,
and
I
think
that
the
origin
of
this
discussion
was
because
they
tried
to
implement
a
feature,
a
dashboard,
and
it
took
something
like
a
week
for
them
to
figure
out
and
the
business
logic
and
how
things
work.
It
was
one
of
the
of
the
complicated
parts
of
the
github
database.
C
C
Can
have
all
the
logic
in
a
field,
but
you
know
sometimes
it's
like
why
it
is
unique
or
what's
the
also
what's
the
the
the
team
that
is
responsible
for
the
for
the
table.
It's
like
doing
a.
A
Yeah
and
that's
what
kathleen
described
as
what
they
needed,
you
know
if,
if
they
get
a
table
in
and
they
have,
the
table
is
not
self-describing
right.
You
have
some
odd
columns
in
there
and
you
can't
just
look
at
and
go
what
is
this
used
for
they
can
they
like
in
this
example,
they'll
have
the
owner.
A
They
know
which
team
to
go
and
ask
hey
what
are
these
columns
for
and
if
there's
no,
and
that's
only
if
there's
no
description
because
right
now,
they
have
no
idea
who
to
ask
they
often
kathleen
often
comes
to
me
directly
like
hey:
do
you
know
who
owns
this
table
now
or
even
things
in
the
channel?
So
this
would
help,
and
then
you
know
questions
she
had
recently
like
what
is
this
column
used
for
and
having
these
comments
on?
A
A
A
A
B
So
it's
good
that
we
start
documenting
that.
The
other
question
you
could
ask-
and
I
I'm
sure
they
also
have
is
like
how
do
they
know
when
these
things
change
over
time
like
when
we
ship
a
migration
that
breaks
those
assumptions
or
changes
that
documentation?
How
do
they
know
that,
or
you
know,
communicate
about
those
things,
because
then
these
these
things
start
to
start
to
get
to
become
an
interface.
A
B
B
I
would
think
it's
just
plain
sql,
so
they
can.
They
probably
don't
need.
B
C
A
document,
the
document
that
you
have
prepared
that
most
probably
provides
anything
that
anyone
wants,
because,
from
a
data
analysis
perspective,
I
think
that
what
you
want
is
to
understand
the
schema.
So,
for
example,
in
this
case
there.
D
C
C
B
C
I
talked
about
the
api
because
the
api
is
a
form
of
documentation
over
our,
even
though
it's
not
one
to
one,
but
it's.
There
is
a
lot
of
documentation
of
how
things
work.
A
So
how
would
someone
that's
new
to
the
data
analysis
team
know
where
to
find
the
the
documentation
that
we've
already
talked
about
with
container
registry?
I
think
that's
where
the
like.
The
table
comment
would
help
right,
just
link
to
the
issue
the
documentation,
whatever
conversation
that
we've
had
so
that
they
have
one
place,
they
can
go.
Look.
B
B
I
think
it
would
be
better
if
we
kept
all
that
information
on
the
code
base,
because
this
is
where,
where
it
lives
right,
the
document
is
going
to
be
outdated,
like
it
probably
already
is
right,
so
I
think
it's
you
know
putting
that
into
the
schema
mix
makes
it
very
close
to
what
you're
changing
in
the
future
dropping
that
column.
Well,
the
documentation
will
be
gone.
Anyways.
A
A
B
Or
there
is
a
there
is
a
markdown
document
for
for
the
documentation
in
the
container
registry
project
itself,
and
you
can
reference
that,
so
it
lives
in
the
same
kind
of
place.
B
A
Is
that
gonna
stay
up
to
date,
though
so,
like
if
you're
in
the
code
and
you're
changing
columns
or
whatever
this
using
this
process
here,
would
make
sure
that
it's
up
to
date
right?
But
if
you
have
a
separate
markdown
document,
that's
acting
as
a
data
dictionary.
In
this
case,
I
can
see
that
getting
out
of
sync
pretty
quickly.
D
C
We
ask
for
every
migration
every
amar
that
has
a
my
relation
to
have
a
change
law.
The
changelog
is
a
separate
file
and
he
you
you
do
not
approve
nmr
without
the
change.
Local,
for
example
you.
If
the
policy
the
process
is
that
if
you
have
a
a
migration.
C
The
database,
you
must
also
change
schema.sql
or
whatever
we
are
going
to
schema
description.
A
Yeah,
I
think
that
should
be
a
part
of
this
as
well,
regardless
of
what
the
final
outcome
of
this
data
dictionary
is.
Okay,
maybe
we
just
think
about
it
and
continue
to
talk
about
this
one
asynchronously,
it's
not
critical
for
13.5,
but
I
know
the
data
team
really
likes
this
idea
and
would
like
to
see
some
progress
on
it.
So
if
you
have
any
more
thoughts
or
ideas
just
feel
free
to
add
them
here,.