►
From YouTube: Database Office Hours 2020-01-30
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).
B
C
B
B
A
There
hey
before
we
start
I,
would
like
to
welcome
Patrick
to
the
team
he
started
last
week.
The
database
group
we're
happy
to
have
you
here,
so
this
is
the
office
hours
call
for
database
and
generally
used
to
talk
about
any
any
kind
of
database
topics
or
changes
that
we
want
to
make
and
stuff
like
that.
A
I'll,
try
to
localize
what
Adam
put
on
the
edge
and
I'm
he's
not
only
call
today
so
Adam
was
asking
about
a
an
issue
that
we
ran
into
where
we
skip
the
database
review,
so
that
would
didn't
make
it
through
database
review
and
the
change
was
a
filter
that
that
doesn't
perform
very
well
and
I.
Think
Adam
is
wondering:
how
can
we
actually
detect
those
query
changes
there,
something
we
can
do
with
danger,
maybe
or
how
do
we
actually
realize
that
Curry's
have
been
changed
in
Aomori?
A
D
I
think
this
is
that
is
at
the
discretion
of
the
marsh
requests
outdoor
and
perhaps
the
back
and
maintainer
I
haven't
reviewed
the
original
mr,
but
I
remember
this
was
query
to
filter
out
some
user
names
like
instead
of
doing
equals,
we
are
doing
equals,
nod
or
something
like
that.
It
was
an
interesting
one,
but
yeah
I
think
mostly
right
now
it
we
require
data
reviews
for
migrations
and
for
queries.
We
don't
specify
what
kind
of
I.
A
Think
I'm
not
too
concerned
with
with
us
skipping
with
a
debrief
you
ready
for
that.
That
was
also
a
time
where
I
think
we
still
had
the
Enterprise
Edition
and
we
were
just
moving
into
a
single
codebase
where
there
was
a
bit
of
confusion.
I
think
around
that
too
and
I
agree
that
the
year
as
a
developer,
you
probably
know
best
what
changes
you're
making.
But
still
it's
a
it's
a
interesting
question.
A
If
we,
if
we
had
a
way
to
sort
of
say
that
oh
these
are
the
queries
that
you'd
your
change
effects,
that
would
be
perfect
for
us.
We
could.
We
could
sort
of
automate
getting
query
plans,
format
and
all
that,
but
it's
really
hard
to
detect
those
those
changes.
I
thought
we
could
probably
run
all
the
tests
and
record
the
queries
and
look
look
what
the
difference
is,
but
it's
I
don't
think.
That's
a
very
good
approach
to
that.
D
And
something
that
worries
me
about
requiring
a
lot
re
review
on
the
finders
folder
is
that
we
have
a
lot
of
finders
and
we
also
will
need
to
least
like
the
finder,
the
finders
under
the
EE
folder.
So
perhaps
that
is
not
the
first
step.
Perhaps
the
first
step
is
to
detect
which
finders
do
need
database
review
like
the
projects
finder,
which
is
like
a
big
one,
and
the
users
finders,
and
the
merge
request
find
they're
like
the
ones
that
we
know
the
ones
that
are
painful
for
us.
A
A
Think
this
is
really
a
problem
for
us.
We
have
this
when
you
look
at
the
project.
Finder
is
like
this
huge
Finder
class.
Where
you
can,
you
can
apply
all
kinds
of
different
filters
and,
depending
on
that,
we
construct
one
sequel:
query
for
you,
so
it's
sometimes
really
hard
to
see
what
what
impact
that
has.
B
D
If
we
are,
you
are
modifying
migrations
or
you're
modifying
files
that
meet
database
review.
A
database
review
is
required.
I
still
need
to
put
some
numbers
on
how
many
of
those
we
have
I.
Don't
think
we
have
that
many,
but
I
have
encounter
at
least
two
or
three,
but
yeah
just
wanted
to
mention
that
should.
D
A
Interestingly,
its
finishes
with
a
sentence
constraint
triggers
are
not
the
solution
and
it
was
interesting
to
read
because
you
suffer
from
a
consistency
problem
there
or
it
has
a
race
condition
where
you,
where
you
don't
catch,
what
you're
actually
looking
for
so
not
totally
sure
this
is
maybe
depend
on
the
use
case,
but
it's
in
general.
There
is
this
race
condition,
so
that
makes
it
a
problem.
A
Was
wondering
if
perhaps
maybe
the
model
is
something
that
can
be
changed
as
well,
so
having
a
need
to
apply
a
unique
constraint
across
two
tables?
Maybe
that
already
suggests
that
the
model
can
be
changed
in
a
way
that
you
can.
You
can
actually
enforce
that
easily
or
easier
I
I'm,
not
sure
about
this.
This
particular
model,
though.
C
Making
I
can
comment
a
little
on
that,
since
this
was
my
merger
quest,
so
yeah.
That
was
one
of
the
thoughts
I
had
was
that
you
know
perhaps
because
we're
seeing
this
need,
maybe
that's
pointing
to
a
bigger
problem
with
the
overall
structure
of
the
tables,
and
so
the
way
things
are
currently
set
up
with
this.
The
entire
like
package
management
systems
is
that
there's
one
central
packages
table
that
just
has
very
basic
table
data
like
name
and
version
and
connects
it
to
a
project
and
then
depending
on
which
package
type
you
have.
C
If
it's
a
NPM
package,
there's
an
NPM
metadata
table.
If
it's
a
maven
package,
there's
not
maven
metadata
table,
and
so
that's
sort
of
just
I
mean
that's
kind
of
like
how
it
was
initially
set
up.
So
that's
the
pattern
we've
continued
to
follow,
but
in
this
case,
with
these
Konan
packages,
there
arises
a
need
to
check
this
uniqueness
based
on
some
of
that
metadata.
Not
just
the
name
and
version
and
I
expect
that
that
this
won't
be
the
only
time
that
this
is
going
to
come
up.
A
Yeah
I
agree
the
with
the
hierarchy
or
maybe
maybe
splitting
that
out
into
individual
tables
is
something
you
can
do
or
I
mean.
You
can
also
think
about
like
denormalizing
stuff,
where
you
extract
that
information
into
yet
another
table
the
information
that
you
need
to
enforce
the
unique
constraint-
and
you
use
that
to
to
do
exactly
this,
but
maybe
you
already
end
up
with
a
full
table
for
the
for
the
coat
and
packages
done
and
nonetheless,
if
I'm
not
sure
how
how
good
it
is,
though,
but
alternative
is
to
the
process
provides.
A
You
is
also
table
inheritance
or
I.
Think
it's
applicable
here
again,
I'm,
not
sure
if
it's
a
good
solution,
but
what
you
can
actually
do
is
also
to
replicate
the
hierarchy
in
the
in
the
database
schema.
So
you
would
actually
have
a
parent
table
with
with
the
common
schema
and
then
child
tables
that
can
add
or
columns
to
that
and
the
child
tables.
They
can
have
individual
indexes.
For
example,
you
can,
you
can
have
a
unique
index
on
on
the
child's
toy
before
the
Konan
packages,
where
you
have
only
all
the
information
available.
A
C
C
There
perhaps
I'll
open
an
issue
for
for
some
more
discussion
about
the
the
way
to
possibly
structure
this
data
in
a
better
way
in
the
future.
I
think
right
now.
It
sounds
like
in
this
specific
case,
to
keep
this
moving,
we're
just
going
to
continue
with
a
validation
that
we
have
in
place,
but
definitely
worth
revisiting.
D
Sure
so
I
was
wondering
if
we
have
some
sort
of
limit
to
bigger
tables.
I
know
we
don't,
but
perhaps
we
should
consider
having
one
projects,
for
example,
it
is
humongous
and
I
think
also
users
and
Alper
is
right.
Also,
application
settings
or
perhaps
application
settings
is
not
the
problem.
It's
not
a
problem
because
it
only
has
one
right
correct,
maybe
supposed
to
only
have
one
record,
but
indeed
in
the
case
of
projects
in
which
we
have
like
millions
and
millions
of
records,
I'm
not
sure
if
it
is
a
good
idea
to
continue
adding
columns.
D
A
Soon
we
can
add
a
default
with
Pospisil
Evan,
but
there
are
other
drawbacks
from
from
those
tables
as
well.
I
think
they,
the
primary
thing
I'm
thinking
about,
is
when
you,
when
you
have
different
use
cases
for
let's
say
projects,
and
so
you
have
this
code
that
looks
that
only
needs
a
part
of
the
projects
table
and
you
have
the
other
perspective
where
you
need
a
different
part.
You
always
have
a
performance
impact
because
you,
you
always
read
the
whole
record
right.
A
A
Maybe
that's
that's
already
an
indication
that
we
have
these
different
use
cases,
and
maybe
the
modeling
should
follow
that
and
we
we
have
them
extract
the
table.
That
is
for
the
one
use
case,
and
then
there
is
the
the
other
one.
Maybe
the
core
use
case
of
the
project's
table
is
different
from
that
I
think
one
prepare
a
AMR,
that's
currently
in
flight
right
to
extract
the
project
settings
table
I.
D
Think
we
have
several
like
project
related
related
tables.
We
have
project
authorizations,
we
have
project
CI,
CD
settings
and
we
have
like
a
couple
of
more
and
I
think
when
it
comes
to
add
a
new
column
to
projects.
We
might
want
to
take
a
look
at
all
the
projects
table
and
perhaps
try
to
find
a
place
there
and
I
also
think
that
it
might
not
be
a
big
deal
if
we
create
another
table,
perhaps
just
with
button
:
instead
of
adding
it
to
the
projects
table
I,
think
that
may
be
another
solution.
A
D
Yeah,
no,
it
was
something
just
to
keep
in
mind
when
reviewing
merge,
request
like
if
we,
if
we
review
one,
that
we
sat
in
a
column
in
the
table
projects
in
this
column,
we
will,
it
can
also
be
fit
in
another
table.
It
might
be
whether
to
move
it
to
another
table
or
to
also
consider
creating
a
new
table,
and
then,
if
none
of
those
options
work
maybe
well.
We
just
added
to
the
projects
table.
F
A
B
A
This
is
sort
of
what
what
led
to
those
white
tables
that
is,
it's
mostly
always
easier
to
just
add
a
column
to
into
an
existing
table
than
to
create
a
new
model,
will
create
a
new
table
and
use
that
I
think
only
the
project
settings
table
what
you're
doing
there
is
only
preparing
this
separate
table
right.
You're,
not
you
know
it's
so.
The
first
change
is
not
to
extract
columns
and
move
them
over,
but
it's
just
to
create
this
table
make
sure
it
is
filled,
so
it's
actually
easier
to
add
columns
to
this
table
right.
A
G
I
didn't
wanna
bother
with
moving
over
columns
and
making
sure
that
all
the
UI
components
and
everything
know
which
which
model
to
write.
So
what,
by
just
creating
the
table,
making
sure
the
project
and
trees
are
there,
it
should
be
easier
to
add
the
columns
to
that
table
and
set
to
instead
to
the
regular
project
table
so
that
it
won't
grow
even
bigger.
A
Another
situation
I
had
recently
was
when
we
added
a
column
in
an
Amaro.
We
also
discussed
if
all
the
records
in
this
table
should
actually
get
a
value
for
it.
So
sometimes
you
add
something,
but
it's
it's
maybe
only
relevant
for
a
subset
of
those
records
for
a
certain
type
of
Records
or
stuff
like
that.
Maybe
goes
a
bit
back
to
also
the
packages
problem
where
you
have
the
these
hierarchies
and
if
it
turns
out
that
only
a
particular
type
of
record
needs.
A
These
additional
information
and
I
think
this
is
also
a
good
indicator
to
say
they
all.
Why?
Why
don't
we
split
that
into
whatever
did
the
type
of
the
use
cases
and
and
split
it
into
a
separate
table?
I
have
there's
one
on
one
relationship,
I
think
that's
always
a
good
question
to
ask
in
the
review.
E
I
was
just
kind
of
thinking
with
having
a
limit
sort
of
on
the
number
of
columns.
I
mean
my
concern.
There
would
be
that
people
were
going
to
see
that
you
know
there's
a
limit
say,
say
we
say
150
columns
more
than
that
is
problematic
at
the
point
they're
adding
a
new
column,
they
start
to
think.
Perhaps
there
should
be
a
new
table,
but
it's
not
really
about
just
moving
that
individual
column
out.
It's
taking.
E
You
know
pieces
of
functionality
that
are
grouped
together
and
building
a
new
table
around
those
in
like
a
schema
design,
type
of
way.
That
makes
sense
not
just
kind
of
reaching
a
limit
and
saying
this
is
bigger
than
we
want
to
be.
So,
let's
sort
of
create
this
ad-hoc
table
that
doesn't
really
group
to
anything
else,
so
I
think
that's
something
that
we
should
try
to.
A
F
I
faced
that
situation
in
a
design
actually
now
I
have
a
feel
for
the
user,
but
I'm
inclined
to
put
it
on
and
want
one
table
to
users.
So
I
think
Meyers,
question
and
Pat's
point
is
exactly
not
I
mean
harshly
I
design
it
better
and
the
reviewer
should
I
point
to
create
a
new
table
or
should
I
say:
hey
just
move
this
to
the
existing
table
and
should
it
depends
only
on
the
column,
size
or
the
domain
knowledge
Oh,
schema,
design.
D
F
E
B
F
A
We
also
see
that,
for
example,
locking
on
those
tables
there's
a
problem
where
you
have
a
lot
of
traffic,
and
this
is
sort
of
an
indicator
that
they
were
used
quite
a
lot
right
and
we
should
be
I
think
we
should
be
more
careful
with
those
tables
than
others.
Obviously
it
make
sense
to
always
consider
that,
but
you
know
the
bigger
the
impact
is
on
the
on
the
tables
that
have
high
traffic,
for
example,
right
yeah,.
B
A
H
Whether
all
the
other
activity
in
that
table,
as
far
as
I
can
see,
is
a
key
references
to
other
tables.
So
you
know
if
it's
a
creating
a
user,
for
example
in
the
first,
it
refers
to
it
just
kind
of
calls
out
to
another
table
almost
getting
wasn't
doing
what
so
that
got
split
up,
yeah,
there's,
there's
some
it's
there.
If
you
want
survival
like.
H
And
there's
been
a
few
suggestions,
so,
in
addition
to
that
serve
at
the
same
time,
housekeeping
was
introduced
on
that
on
that
table
to
only
keeper
years
data
also
and
that
Housekeeping's
got
expanded
since
then.
So
we
came
in
more
day
there
now
and
we've
had
customers
saying
that
their
activity,
data's,
vanishing
and
first
pass.
We
tend
to
say
well,
yeah,
there's
housekeeping
on
that,
and
obviously,
if
they're
still
on
an
old
version,
that
housekeeping
is
fairly
aggressive
and
they're
more
later
notice
it.
H
But
then
there's
been
a
few
hints
that
random
other
data
was
vanishing
as
well
much
more
recent
data,
and
that
was
why
that's
that's
why
I
was
looking
into
that
for
a
customer
because
they
had
a
project
with
fairly
low
activity
in
it
and
and
so
when
data
banished
a
over
a
year.
It
was
very
obvious
because
I'm
a
lot
much
activity,
but
also
they
had
like
sort
of
launched
creations
there.
H
They
think
they
exceeded,
want
to
be
merged
in
the
activity
history
for
the
bond
creation
from
equals,
who
I
wasn't
was
missing
and
that
seems
to
have
coincided
with
them.
Upgrading
to
the
version
which
all
either
to
the
version
or
through
the
version,
which
did
the
tape
was
split
but
also
introduced
the
housekeeping.
We
never
really
got
to
the
bottom
of
it.
H
It's
a
difficult,
interesting
they
just
just
while
it's
on
my
mind,
one
of
the
possible
work
events
for
that
might
be
to
back
up
and
restore
the
repositories,
because
when
you
do
that
we
add
activity
entries
and
I'm
wondering
if
the
backup
and
restore
process
literally
has
database
records
for
the
activity
table
or
whether
actually,
as
opposed
as
as
the
restore
is
done.
The
get
date
has
passed
and
generates
that
the
records
but
had
reason
to
play
around
with
that
during
was
together.
I.
A
B
A
D
D
So
in
my
head
a
serial
number,
it
is
like
a
kind
of
a
long
number,
so
I
wasn't
very
sure
of
using
an
integer,
because
we
could
have
like
an
error
of
range
out
of
error
out
of
range
or
something
like
that
so
I
suggested.
Perhaps
it
might
be
better
to
use
on
the
string,
and
then
this
person
explained
our
according
to
this
standard.
A
Yeah
that
that
was
I
was
wondering
if
that
is
sort
of
similar
to
that
you
know
when
we,
when
you
still
get
jaws,
we
also
put
them
into
binary,
because
then
you
don't
have
to
store
the
encoding
and
it's
it
boils
down
to
like
half
the
storage
needs.
Then
then,
for
a
string
and
this
guy's
is
sort
of
it-
is
20,
20,
bytes
long
writers,
here
a
number
so
yeah,
that's
that's
beyond
the
integer
range,
I
wasn't
sure
about
numeric
types.
A
D
F
D
I
have
no
idea
about
that
document.
I
will
make
sure
to
link
it
also
on
the
database
guides.
B
D
B
A
In
some
places
we
still
have
I
think
this
was
introduced
at
some
time.
So
this
is
just
suggestion
and
in
some
places
we
still
have.
We
still
store
Shaw's
as
string,
and
then
we
even
join
tables
were
in
one
table.
Has
it
as
a
string
and
the
other
one
was
binary,
and
then
you
have
to
really
fiddle
around
to
you
know
to
express
that
joined
condition
correctly,
with
like
considering
encoding
and
stuff
like
that,
so
I
think
it's
much
easier
to
just
just
go
for
a
binary
everywhere
for
those
those
type
of
things
and.
A
D
A
A
Then
I'm
shortly
going
to
advertise
the
structure,
sequel
change,
so
there
is
an
Amaro
out
there.
If
you
haven't
seen
that
yet
where
we
change
the
way
we
track
the
rails
schema
or
the
database
schema
from
change
it
from
schema
RB
to
structure
sequel
in
hopes
of
using
more
at
once,
those
features
which
is
much
easier
than
because
you
don't
have
to
teach
or
else
the
tricks,
but
you
rather
use
a
plane,
sequel
schema.
Dump
any
comments
on
that
appreciated.
There
is
a
dependency
to
omnibus
and
charts
that
we
discovered.
A
That
is
because
new
installations,
they
they
start
from
scratch
using
that
schema
and
the
right
tasks
are
slightly
different
but
other
than
that
I
think
looks
pretty
good,
and
maybe
we
can
merge
that
soon.
This
is
also
preparation
for
partitioning
I
think
it
might
makes
it
much
much
easier
to
use
that
going
forward.
A
A
This
schema
tracking
and
whenever
you,
whenever
you
run
the
migrations,
you
get
a
full
schema
Dom
from
your
local
database,
similar
to
what
you
what
you
did
with
schema
Robbie
or
you
would
check
in
the
changes
for
structure,
sequel
and
it
may
be
a
little
bit
trickier
to
figure
out
which
changes
are
or
actually
need
committing,
or
what
are
the
changes
that
are
only
related
to
the
migration
that
you
ran.
A
I
think
this
problem
also
pops
up
pops
up
with
the
schema
Robbie,
where
migrations
are
applied
out
of
order,
and
then
you
have
to
figure
out
what
relates
to
your
database.
What
I
typically
do
is
I
start
from
scratch.
I
reset
my
database
to
the
master
schema
and
then
I
run
the
migration
and
eat,
and
you
have
to
change
that.
You
want
basically
other
than
that
I
think
it's
I
I'm,
hoping
it's
a
little
bit
better
on
the
conflicting
side,
so
we
always
have
in
schema
Robbie.
A
We
always
have
this
conflict
with
the
schema
version,
so
I
think
this
happens
to
pretty
much
every
amar
that
changes
the
schema
you
run
into
this
configure.
You
fix
that
later.
I'm,
hoping
that
goes
away
with
the
structure,
is
equal
because
that
Traci
a
little
bit
differently
other
than
that
I.
Don't
think,
there's
there's
a
lot
of
differences
left.
A
Well,
I
think,
ultimately
we
can
remove
it.
We
don't
need
anymore,
so
far
and
EMR
I've
just
put
a
comment
into
it
and
I'm
think
I'm.
Also
raising
an
exception
of
you
still
include
that
it
would
blow
up
in
CI
and
making
a
note
that
this
isn't
being
used
anymore
and
we
should
use
structural
sickle
instead.
A
A
We
just
discussed
this
here
before
I
think
we
will
need
to
have
some
experience,
seeing
that
in
production
to
tune
the
retry
and
the
lock
timeouts,
and
all
that
and
the
first
migration
that
we
are
going
to
see
using.
That
is
just
dropping
unneeded
tables,
but
is
difficult
in
so
far
that
the
those
tables
still
have
a
foreign
key
constraint
to
protects,
for
example,
and
hence
you
need
a
lock
on
the
projects
table
and
yeah.
B
A
H
A
comment
if
I
introduce
myself
in
a
previous
one
but
I'm
volunteer
to
be
supports.
They
all
counterpart
for
the
database
teams
us
that's
kind
of
why
I'm
here,
joking
information,
I've
linked
to
the
Job
Description,
though
it's
about
kind
of
knowing
about
database
issues
that
customers
are
hitting
and
surfacing
those
and
knowing
about
what's
going
on
with
databases
and
taking
out
information
down
into
supporting
our
customers.
So
I
thought
this
one
might
be
of
interest
from
last
weekend.