►
From YouTube: Database Office Hours 2019-11-21
Description
Agenda: https://docs.google.com/document/d/1wgfmVL30F8SdMg-9yY6Y8djPSxWNvKmhR5XmsvYX1EI/edit?usp=sharing (GitLab internal)
B
C
A
A
D
I
just
think
so,
when
we
roll
that
12.5
of
ordering
the
deployment
the
migrations
have
been
executed.
First
and
since
we
have
one
single
database
between
canary
and
and
production,
actually
a
database
migration
broke,
an
existing
and
working
data
is
queried
from
12.4,
and
this
was
failing.
Loading
like
the
security
scan
results
until
we
actually
officially
released
12.5
and
the
culprit
I
think
address
linked
it
and
I.
Also
in
the
mercial
ask,
it
was
I
think,
because
the
query
used
basically
a
string
as
a
select
statement,
so
we
didn't
reference
the
the
table
relation
directly.
D
We
just
put
the
column
name
there
and
as
soon
as
the
migration
happened
with
the
same
column,
name
in
you
know
join
table
just
yeah
the
career
field,
because
the
curriculum
I
couldn't
decide
which
table
to
use-
and
here
it's
coming
in
that
hey
how
much
sequel,
pure
sequel
should
we
use
in
the
query
should
be
always
try
to
enforce
that
here.
Even
if
it's
a
straightforward
select
statement
or
a
straightforward
expression
should
be
enforced
to
use,
RL
or
or
activerecord.
If
it's,
if
it's
possible,
to
give
the
list
of
columns
I.
A
D
Yeah
I
wouldn't
say
you
know,
restrict
the
writing
pure
sequel,
but
when
it's
needed
we
should
be
as
explicit
as
possible
column
names
and
this
specific
category,
probably
yeah.
It
was
a
really
hard
catch.
I
mean
we
didn't
catch
it
during
during
review
and
it's
a
really
edge
case
right,
because
what
are
the
chances
for.
A
Sure,
and
in
that
sense,
is
also
interesting
to
look
at
the
testing
that
we
do
I.
Think
the
if
I
understand
that
correctly,
then
basically
running
the
migrations,
while
the
old
version
of
the
code
was
live,
basically
caused
that
problem,
and
that
is
something
that
you
can't
test
for
when
you
only
run
the
tests
on
one
version
of
your
application.
So
I
think
this
also
goes
back
to
testing
know
down
ten
upgrades,
which
is
something
we
don't
do
to
my
knowledge.
A
So
our
testing
basically
goes
like
oh
run,
all
the
pending
migration
or
basically
run
all
the
migrations
and
then,
with
the
current
version
that
you're
testing
on
run
all
the
tests
and
if
we
had
something
I
was
basically
testing.
Further
now
note
on
time
steps
we
would
need
to
be
doing
things
like
running
with
the
previous
version,
applying
the
migrations
and
then
running
the
tests
on
that
right
before
we
go
on
and
run
on
the
new
version,
and
then
there
is
the
same
issue
with
the
post-deploy
migrations,
I
guess.
D
Yeah,
but
that
actually
would
have
called
the
issue
and
I
mean
we,
it
shouldn't
be
part
of
the
main
pipeline.
Maybe
when
it's
merged
to
master,
it
would
be
kicked
off.
Its
basically
doubles
the
test
run
time,
because
you
have
to
test
it
twice,
only
with
migrations
and
otherwise.
In
the
new
code,
yeah
I.
A
A
Multiple
major
upgrades
a
few
if
you're,
oh,
if
you're
too
far
behind,
but
then
you
can
basically
upgrade
from
any
minor
version
to
any
other
minor
version
and
the
same
major
major
version
and
stuff
like
that.
So
there's,
if
you
think
about
the
ultimately
the
the
amount
of
paths
that
you
would
have
to
test
for
that
you
would
have
to
cover
this
area
like
really
quite
a
lot.
I
guess.
B
A
A
D
D
B
A
The
same
I
think
it's
also
difficult
to
detect
when
you,
when
you
think
about
really
custom
sequels,
where
you
you
write
a
bunch
of
sequel,
you
included
and
some
other
active
record
curry,
it's
quite
hard
to
detect
from
from,
like
a
static
analysis,
point
of
view,
but
on
the
other
hand,
if
we
we
run
a
lot
of
tests,
so
we
might
be
able
to
see
the
full
queries
that
we
run,
but
then
parsing
those
and
making
sure
that
we
have
explicit
names
could
also
be
difficult
or
maybe
not.
You
know,
balance
out
with
the.
D
B
D
C
Perhaps
we
could
be
like
our
rake
tasks
that
prints
the
attributes
that
are
repeated
across
tables
and
then
build
something
up
on
top
of
that,
but
that
might
be
also
complicated.
Like
I
see
it
like
in
different
stages,
because,
as
Andrea
said,
checking
that,
with
the
static
analysis
might
be
a
little
bit
tricky.
D
E
E
D
B
A
E
We
are
active
record,
always
generates
two
plural
form
of
the
long
table
name
and
thanks
thanks
to
Ruby's
dynamism.
You
know
people
are
able
to
create
another
column
names
in
a
different.
You
know
creative
ways
like
like
metaprogramming
and
so
on.
So
it's
going
to
be
hard
to
check
in
Ruby,
particularly
but
at
least
we
can
in
the
documents
we
can
write
this
table,
name
that
column
name
and
we.
A
Yeah
I
was
I
was
wondering
if,
like
there
is
a
migration
in
this
case,
where
we
add
a
column
that
sort
of
is
ambiguous
across
related
tables.
So
right
so
does
this,
mr
added
this
column,
and
then
there
is
other
tables
that
relate
to
each
other
with
foreign
key
constraints,
and
they
also
have
similar
columns
so
the
likelihood
of
having
joins
across
them.
It's
quite
high,
I
guess
with
those
foreign
keys.
A
E
E
C
Yeah
I
was
thinking
of
building
like
a
rekt
rekt
asked
at
least
they
duplicated
attributes
across
tables
and
then
use
that
source
to
feed
a
rule,
Cup
rule
and
then
check
alike.
Okay,
someone
is
a
dinner,
not
revealed
these
values
already
listed
on
the
duplicated
attributes
and
theirs
might
be
a
chance
if
you
use
this
attribute
that
the
query
is
going
to
be
like
it
is
not
going
to
be
very
straightforward.
B
D
Just
out
of
curiosity,
instead
of
a
let's
say,
I
have
a
select
statement
which
contains
like
columns
without
table
name
and
if
I
call
a
plan
on
it.
So
I'm
explaining
it
with
the
explain
automatically
resolved
the
the
table,
because
if
we
always
execute
explained,
then
we
can
say
that
this
query
is
actually
using
that
specific
table
and.
E
D
Thinking
about
you
know
comparing
the
the
output
of
the
explained,
which
contains
the
tables
and
the
columns
that
are
queried
with
the
Select
statement
in
the
basically
in
the
pure
sequel
query
before
we
before
it's
sent
to
the
sequel,
server
and
just
matching
that
hey
in
the
plan.
You
have
issues:
dot
user
ID
and
in
the
sequel
query
you
just
have
a
user
ID.
A
D
Yeah,
but
this
would
happen
before
actually
this
problem.
What
I
wanna
check
is
that
in
the
Select
statement
you
are
explicitly
passing
in
the
table
name
and
the
column
name.
That's
the
only
thing
I
wanna
want
to
check
here.
So
if
I
get
the
explicit
table
name
and
column
name
from
the
plan,
I
can
cross-check
it
with
my
query,
which
has
only
the
column
and
I
can
detect
here.
There
is
a
mismatch
here.
The
result
is
you
for
network
specific,
specifically
about
name.
D
A
B
D
A
B
A
D
D
B
A
Yeah
I
guess
what
we
can
do
is
add
to
the
documentation
and
make
people
aware
or
as
we
review.
Mrs
look
for
that.
So
if
you
see
a
custom
cycle
going
on
or
a
custom
column
names
and
look
for
that,
and
we
can
see
how
many
issues
we
run
into
before.
We
tackle
that
the
more
difficult
detection
of
that
excess.
D
D
I
had
the
next
one,
it
was
from
the
previous
session.
So
we
had
this
performance
issue
about.
You
know
passing
in
huge
arrays
to
to
active
record
and
that
resulted
in
huge
database
queries
and
we
were
discussing
that
hey.
Maybe
we
should
somehow
detect
these
or
at
least
limit
or
or
blow
up
when,
when
we
detect.
D
I
cannot
really
see
them
what's
what's
being
executed
them
or
some
graph
owner
I'm
not
quite
familiar
with
it.
So
I
don't
know
if
you
know
somebody
who
can
maybe
help
it
could
be
an
interesting
step
to
see
it.
You
know,
maybe
we
have
like
crazy
queries
behind
the
scenes
and
and
like
the
what
we
run
this
post
breast
checkup
just
doesn't
catch
it
because
it
doesn't
execute
it
that
frequent.
A
No
I'm
pretty
sure
we
have
these
things
going
on
quite
a
bit
just
if
you
pull
up
the
log
of
database
machines.
Sometimes
there
is
like
patterns
where
you
have
like
really
long
queries
coming
through,
so
yeah
definitely
worth
worth
figuring
that
out
or
detecting
that
you
mentioned,
you
didn't,
have
access
to
keep
honor
and
the
logs.
A
D
A
What
we
don't
do
currently
is
we
don't
lock
each
and
every
query.
So
it's
not
that
you
have
the
full
lock
available
in
there,
but
we
do
log
the
queries
that
take
longer
than
one
second.
That
is
basically
because
you
we
have
so
many
queries
going
on
I
would
be
really
expensive
to
lock
all
of
these,
but
I
guess
it's
sort
of
fair
to
say
that
if
you,
if
you
have
those
issues
where
you
put
in
like
thousands
of
parameter
values,
then
those
might
also
take
long.
E
Actually,
that's
a
review
which
I
passed
on
you
because
I
was
not.
You
know,
I
didn't
decide
how
to
proceed.
I
mean
I,
but
I
want
to
discuss
here
in
the
team.
So
there's
a
there's
an
index
for
for
this
table,
which
is
software
licenses
like
MIT
or
GPL,
and
currently
there
is
no
index
on
the
name
field
which
is
unique
and
the
mr
wants
to
add
a
like.
They
make.
This
unique
is
index
okay
and
there
are
like
800
software
licenses
in
github.com
and
to
have
all
them
are
duplicate
redundant.
E
So
the
mr,
which
is
here
the
code
is
here,
which
I
reviewed
practically
first
drops
12
public,
8
values,
reassigns
them
to
the
correct
places
so
get
resolved.
The
duplication
removes
the
current
index
and
heads
concurrently,
a
new
unique
index,
which
is
the
same
index.
Unique.
Okay
is
the
problem
clear.
E
E
First,
the
data
migration
isn't
reversible
should
I
make
this
an
issue
is
a
reviewer
right.
I
mean
he's
like
basically
Auto
800
software
licenses,
by
name.
Let's
say
there
are
two
MIT
license
and
the
queer
is
deleting
12
of
them
and
it's
irreversible.
It
should
be
an
issue
because
in
the
documents
it's
written
that
I
have
to
have
like
reversible
data,
migrations.
A
Now,
thanks
for
asking
that
is
something
we
I
think
we
were
currently
discussing.
We
haven't
made
a
good
practice
of
requiring
all
the
migrations
to
be
reversible,
but
we
were
sort
of
in
that
in
that
discussion
figuring
that
out
personally
I
think
the
the
problem
is
when
you,
when
you
migrate
things
and
you
lose
that
data.
A
A
D
In
this
particular
case,
it's
I
think
it's
just
a
little
occasion,
and
even
if
we
believer
the
migration
after
the
application,
we
everything
should
be
still
operational
as
far
as
I
can
see.
So
you
couldn't
break
the
application
and
there
wouldn't
be
any
data
loss
from
the
from
the
user
point
of
view.
I
guess
I'm
not
sure
if
I
understood
correctly
this
that
the
role
of
this
table,
but
just.
A
So
I
guess
we
can
look
at
the
worst
case.
That
can
happen.
So
let's
say
there
is
a
park
in
the
migration
where
we
were
trying
to
duplicate
stuff
and
reassigning
those
or
you
know,
removing
the
duplicates
and
making
sure
that
the
Frankie's
are
are
updated
and
we're
making
a
mistake
and
we're
basically,
maybe
maybe
removing
records
that
we
didn't
intend
to
remove
or
something
like
that
and
that
cuz
we
would
be
in
a
very
good
situation
when
we,
when
we
can
still
reverse
that,
and
we
still
have
the
original
table
in
place.
E
In
most
cases,
it's
quite
difficult
for
the
author
to
ensure
a
data
migration
irreversibility
in
our
context
and
I
would
like
to
like
in.
In
my
experience
in
some
other
past
experience,
we
used
to
have
a
redundant
table
called
migrations
which
we
would
use
as
a
like
temporary
store
like
we
would
put
there
like
any
data
temporarily
and
in
case
you
got
in
trouble.
This
was
a
Jason
B
table
in
case.
We
need
to
revert
it.
It
will
just
grab
to
date
that
kind
of,
but
currently
gives
up
application.
E
E
A
So
yeah,
it's
always
a
always
afraid
of
what
you
could
do
here.
If
you
don't
have,
the
if
you
really
wanted
to
make
it
reversible
is
to
just
copy
the
table
before
you.
You
know
before
you
change
it.
So
this
this
is
relatively
straightforward.
You
can
do
a
create
table,
my-my-my
back
up
basically
and
then
just
select
from
the
original
table.
You
don't
need
to
have
any
nexus
or
stuff
like
that.
A
E
C
E
E
E
A
I
think
it
makes
sense
to
to
talk
about
that.
I
mean
what
we
don't
want
to
have
is
those
even
those
simple
migrations
to
failure
deployment,
because
that
that
you
know
puts
the
burden
on
our
delivery
team
to
figure
out
what's
going
on
and
then
revert
those.
So
it's
definitely
worth
worth
talking
about
that
I'm.
Making
sure
that
this
is
consistent,
maybe
I
can
I
can
summarize
how.
A
Maybe
that
the
concept
works
works
together
with
a
unique
constraint
and
rare
or
unique
validation,
rails
and
the
and
the
unique
constraint
index.
So
what
do
you?
What
you
can
do?
We
have
like
basically
have
three
stages
where
you
you,
you
know
you
can
run
a
regular
migration
with
the
old
code
that
is
live.
A
Currently,
then
you,
you
update
the
code
and
your
application
has
both
the
new
schema
and
the
new
code
running
and
then,
at
some
time
later
you
run
the
post,
deploy
my
Gration
right
and
in
this
case,
what
we
do
is
we
we
have
a
post,
deploy
my
Gration
that
makes
this
index
yuning
in
the
end.
This
is
the
goal
of
that
migration
right
and
the
like.
A
That
is
that
you
have
to
teach
the
application
to
not
have
those
duplicates
or
not
introduced.
Those
duplicates
anymore
right
and
I.
Think
that
adding
this
uniqueness
validation
is
see
actual
actually
the
right
way
of
doing
that,
because
then
you
make
sure
that
the
application
that
is
running
while
you
execute
the
post
deploys
doesn't
produce
any
new
duplicates
I'm
coming
in.
You
run
the
cleanup
in
the
post,
deploy
and
at
this
point
in
time
you
you,
you
can
be
sure
that
there
are
no
more
duplicates
coming
in
and
you
can
just
change
the
index.
E
A
We
could
have.
What
could
happen
is
that
you
deploy
the
code
change.
You
have
this
unique
validation
in
place
and
then,
until
you
add
the
unique
next
year
and
remove
the
duplicates,
maybe
the
update
functionality
is
broken
for
the
user,
because
when
you
try
to
save
than
all
there
is
there,
is
there
isn't
duplicate?
No,
no
I
can't
deal
with
that
until
you
remove
the
duplicate
right,
I.
C
Should
we
include
the
uniqueness
validation
on
the
model
or
not
like?
There
is
a
slight
chance
there,
yeah
I
am
Not
sure
there
is
particular
there
is
a
slight
chance
that
someone
is
updated
at
the
same
time
while
the
migration
is
in
executed,
and
then
that
is
going
to
be
a
problem,
but
it
shouldn't
be
like
a
small
like
a
small
amount
of
amount
of
time
and
then
suddenly
everything
is
going
to
be
okay,
because
the
migration
is
already
executed.
E
A
Don't
have
the
exact
timing,
but
this
this
is
sort
of
the
post.
Applause
is
the
step
that
is
currently
being
executed
after
the
code
change
happens,
although
I
think
we're
also
discussing
to
delay,
or
there
have
been
discussions
about
delaying
this
supposed
to
blow.
Migration
is
quite
a
lot
to
guess.
It's
good
to
not
make
any
assumptions
about
that.
A
A
E
Mine
I
also
linked
a
previous
post
migration.
We
really
took
this
literally
to
the
limits
by
checking
a
hundred
attempts,
and
you
know
finally
reporting
we
give
up
because
index
unification
because
of
duplicates.
You
know
something
like
that.
I
also
don't
know
how
to
like
this:
not
this,
maybe
no
traffic
table
should
we
and
first
such
you
know,
policies
too
hard
or
too
low.
Because
then
the
author
could
feel,
like
you
know,
it's
a
little
issue,
sometimes
behind
the
future
flag.
No,
and
we.
A
E
A
E
A
A
Okay,
other
thing
I
wanted
to
point
out
very
minor
issue
with
this
migration
is
we
we
basically
replacing
an
index
and
the
the
more
straightforward
way
of
doing
that
is
removing
the
index
and
then
creating
a
new
one.
But
knowing
that
again,
this
is
not
transactional
and
also
be
the
index
creation
can
fail.
It
may
leave
you
in
a
state
where
you
don't
have
any
index
anymore
for
some
time.
You
know,
and
that's
always
the
case,
even
if
things
go
go
well.
A
That's
always
the
case
between
you
know,
moving
the
index
and
creating
that
because
the
creation
can
actually
take
a
Walter.
Well,
I
tend
to
suggest
is
to
check
if
we
can
just
flip
the
order
of
that.
So
you
first
create
a
new
index
with
a
different
name
and
then
and
then
remove
your
one
when
you're
done
that's
not
as
convenient,
because
you
have
to
specify
the
name,
but
it's
sort
of
usually
easy
to
do,
and
you
don't
end
up
in
a
situation,
although
it's
unlikely
to
happen,
but
it's
still
not
great
I
guess
so.
E
A
E
Anyway,
I
passed
it
to
Myra.
So
sorry,
Myra
I
was
like
you
know
it's
hard
to
make,
because
when
you
read
the
documentation,
you
have
to
be
very
strict,
but
real
life
is
like
you
know,
you
don't
wanna.
Finally,
also
I
am
in
the
very
opposite
timezone
with
the
water,
so
it
becomes
very
difficult
and
Myra
is
closer.
Now
it's
gonna
be
easier,
I
think
is
in
Hawaii
or
something
I'm,
not
sure.
A
A
It's
about
like
migration.
Instead
that
relate
to
larger
tables
or
heavier
used
tables,
and
how
we
can
deal
with
those
exclusive
locks-
and
sometimes
that's
really
subtle.
We've
talked
about
that
before,
where
you
drop
an
empty
table,
and
that
has
a
foreign
key
constraint
to
a
lot
to
have
you
heavily
used
one
and
that
causes
a
problem.
I
think
the
discussion
is
really
interesting
and
there
is.
A
There
is
a
proposal
to
retry
with
low,
lock
timeouts
that
is
interesting
and
currently,
where
I
find
it
very
interesting
to
talk
about
the
lock
queue
problems,
even
though
it's
maybe
not
as
relevant,
because
I
think
the
retries
is
actually
a
good
good
step
to
take.
It's
probably
fixing
most
of
the
things
for
us
still.
The
identity
of
discussion
is
quite
interesting.
I
just
wanted
to
point
that
out,
if
you're
interested
in
typing
into
that.
E
A
And
for
the
for
the
retries,
what
I
found
interesting
is
that
when
you
basically,
the
problem
is
when
you
in
queue
your
DDL
statement,
and
you
basically
asked
to
get
that
exclusive
look.
Then
you
already
block
any
any
other
requests
that
are
coming
enough
to
use
because
of
this
lock
here
and
you,
and
as
soon
as
there
is
a
request
for
an
exclusive
lock
than
any
any
other
requests
for
locks
coming
in
are
going
to
be
blocked
because
of
Adam.
A
A
So
that's
the
problem
and
I
think
that's
why
we
should
get
the
the
lock
time
autumn
place
so
that
we
that
we
control
the
amount
of
time
that
you
can
spend
on
the
lock
you
to
to
get
that
lock.
However,
it
also
reduces
the
likelihood
of
you
getting
you
actually
getting
or
succeeding
to
to
get
that
lock.
So
you
want
to
retry
that
quite
a
lot
and
ultimately
I
think
what
your
eggs
asking
from
the
from
the
delivery
team's
perspective
is
that
we,
what
do
you?
A
B
D
D
E
A
That's
true,
I
think
it's
also
worth
to
separate
two
types
of
migrations.
I
think
there's
ones
that
we
discuss,
for
example
like
dropping
tables,
dropping
foreign
key
constraints
and
these
kind
of
things.
That
is
something
you
can
easily
delay
and
say,
like
oh
yeah,
I
I
want
that
to
get
done
at
some
point,
but
I,
don't
I,
don't
care
when
that
happens.
A
So
we
might
just
easily
do
that
and
in
the
background,
during
weekends
or
whatever,
we
don't
really
care
about
it
and
then,
on
the
other
hand,
the
a
migration
like
adding
a
column
that
something
you
can't
delay
you.
You
will
have
to
do
that
with
your
deploy,
because
as
soon
as
you
deploy
the
code
change,
you
want
that
column.
So
it
has
to
happen
and
even
though
say
like,
like
we
discussed,
they
require
X
exclusive
locks.
They
may
actually
suffer
from
the
same
problems.
I
mean.
D
You
can
put
the
feature
that
you
are
developing
behind
the
feature
flag.
So
then
the
code
is
not
executed
until
the
migration
is
finished
in
the
background,
but
yeah,
that's
who
knows
when
it
will
be
executed.
So
maybe
they
released
ten
point
twelve
point
six
and
in
the
next
three
days
we
automatically
successfully
adding
the
column
and
of
each
I
just
enable
itself.
So
it's
not
that
reliable.
E
E
E
E
D
A
What
has
also
come
up
in
that
discussion
is
that
the
ultimately,
the
problem
that
we
suffer
from
is
the
high
traffic
on
some
of
those
tables,
for
example
namespaces
or
projects
or
users.
Those
are
large
tables,
and
also,
why
tables
that
that
are
that
have
a
lot
of
traffic
and
that's
why
we
have
those
problems
and
if
we
split
those
down
into
like
multiple,
more
narrow
tables,
that's
a
good
because
anyways
and
we
basically
we'd
be
able
to.
A
We
probably
have
tables
that
that
don't
get
the
same
amount
of
traffic
as
the
original
ones
and
then
adding
adding
a
column
to
those
becomes
easier
because
you
don't
don't
have
this
or
you
know
that
that
high
level
of
traffic
anymore.
On
the
other
hand,
you
still
have
this
original
table
that
you
use
to
reference
a
user,
for
example,
that
probably
doesn't
Maori
contend
like
user
ID,
user
name
and
one
of
the
more
the
core
user
attributes,
and
you
still
from
from
all
those
other
tables
that
you
splitted
from
from
the
original
file.
A
You
still
reference
the
the
original
table
and,
if
you
add
another
table
that
is
sort
of
referencing
the
the
original
table,
then
you
still
have
that
problem,
because
you,
you,
then
add
a
foreign
key
constraint
pointing
to
this
table
and
still
need
an
exclusive
lock
for
that.
So
problem
goes
away
for
quite
a
few
things:
I
guess
where
you,
where
you
add
columns
to
the
other
tables
I,
don't
have
a
lot
of
traffic,
but
you
still
suffer
from
the
same
problem
as
soon
as
you
touch
the
original
table.
That
has
a
lot
of
traffic.
B
B
B
D
Be
to
be
consider
something
like
that,
not
for
the
core
code
tables,
but
let's
say
a
special
feature
that
we
a
new
feature
that
we
develop
and
basically
we
don't
really
need
referential
integrity
if
we
have
if
we
are
deleting
a
project
or
a
repository,
it's
okay.
If
records
are
staying
around
for
a
while
in
the
other
tables
and
a
regular
job
can
actually
clean
those
out
and.
A
You
can
also
get
a
lot
of
benefits
from
having
foreign
key
constraints,
because
you
don't
have
to
care
about
the
consistency
and
clean
things
up
and
deal
with
broken
broken
relationships,
and
if
you
you
can
manage
to
remove
those
I
think
there
is
you.
You
probably
still
be
able
to
cope
with
that,
but
you
have
to
sort
of
be
able
to
cope
with
that
from
the
application
side
of
that
adds,
complexity
as
well
I
wouldn't
be
like
removing
all
the
foreign
key
constraints
that
we
have,
because
we
really
benefit
from
from
those
right.
We.
B
E
A
A
A
C
A
I
know
it's
not
solid.
We
we've
reached
out
to
vendors
crack
reached
out
recently
and
we
are
still
waiting
for
some
responses
and
I'm
trying
to
figure
out
which,
which
of
those
we're
going
to
get
I.
Think
that's
at
least
my
state
of
mind
there.
So
you
don't
have
you
didn't
miss
anything
still
coming
up
with
so
planned?
It's
just
that.
We
don't
have
two
sided
yet.