►
Description
Join the team as they explore the latest many-to-many mapping features implemented for EF Core 5.0 including skip navigations and more!
#EnityFramework #EFCore #DotNet
A
A
And
we
are
live
and
in
action,
welcome
everyone
to
another
meeting
community
stand
up
gathering
of
the
the
minds
behind
entity
framework
and
the
community,
which
is
you
and
really
quick,
just
want
to
introduce
the
team
that
we
have
with
us
today.
My
name
is
jeremy
likness,
I'm
a
program
manager
at
microsoft,
for
net
data
and
a
big
part
of
that
is
entity
framework
core
arthur.
B
A
A
Let's
pull
these
links
up
right
here
and
I'll,
give
you
the
links
that
I'm
looking
at
so
this
first
link
is
mapping
and
using
sql
server
stored
procedures
with
ef
core
power
tools.
This
is
a
extension
that
you
can
get
for
entity
framework
core.
It
has
a
lot
of
killer
features
in
it
and
what
this
blog
post
is
showing
you
is
how
to
basically
integrate
these
stored
procedures
using
the
features
of
the
tool.
A
C
Yeah,
so
this
is
full
text
search
which
is
kind
of
like
using
a
search
engine
against
your
data.
I
had
a
little
personal
project
and
I
had
to
sort
of
hammer
out
the
best
way
to
do
this,
so
I
thought
I'd
share
it
with
everyone.
There's
a
lot
of
rough
edges,
but
it's
a
really
cool
technology
once
you
get
it
working,
and
so
this
is
like
you
search
for
migrate
and
it
finds
like
migrations.
A
Nice
yeah,
I
implemented
a
search
algorithm
for
my
blog.
Unfortunately,
it
was
a
a
hard-coded
javascript
parsing
over
json
files,
so
this
seems,
like
it'd,
be
a
much
better
approach.
Let's
go
to
the
third
link.
This
is
a
blog
post
that
I
wrote
about
inspecting
and
mutating
iquariable.
So
this
is
a
pretty
advanced
look
at
expressions
if
you've
worked
with
entity
framework.
A
Core
you've
worked
with
link
and
behind
link
is
a
set
of
expressions
and
what
this
does
is
it
explores
what
those
expressions
look
like
how
to
parse
and
navigate
those
expressions,
and
it
also
covers
a
little
bit
about
how,
if
you
want
to
intercept
or
navigate
or
even
mutate,
the
expressions
how
to
do
that.
So,
for
example,
let's
say
you
want
to
enforce
a
policy
on
queries
that
are
passed
through
your
system.
This
will
give
you
a
little
bit
of
insight
into
that.
B
A
Yeah,
I
think
it's
the
under-appreciated
part
of
the
the
framework.
I've
been
learning
a
lot
that
you
can
do
with
that
and
then
last
but
not
least
before
we
get
into
our
demo,
we've
released
our
official
guidance
for
using
entity
framework
core
with
blazer
server,
and
so
you
can
find
that
documentation
here.
A
It's
linked
to
both
from
the
entity
framework
core
documentation
or
it
will
be
by
the
end
of
this
week,
but
it's
here
as
part
of
the
navigation
for
asp.net
core
documentation,
but
this
not
only
describes
our
recommendations
for
how
to
use
db
contacts
in
the
ef
core,
but
it
also
includes
a
reference
application,
there's
a
version
for
3.1
and
there's
a
version
for
5.0,
which
is
in
preview.
Obviously,
but
both
versions
are
a
full-fledged:
you
can
get
a
grid
search,
the
grid
sort,
the
grid
add
items
edit
items,
it
has
optimistic
concurrency
built
into
it.
B
This
is,
this
is
very
cool.
I
mean
this,
isn't
just
somebody
putting
together
a
quick
piece
of
guidance.
This
is
in-depth
guidance.
It's
been,
you
know,
we've
discussed
and
reviewed
this
with
steve
sanderson
and
javier
and
dan
roth
and
people
on
the
blazer
team.
So
yeah,
you
really
should
check
this
out.
It's
pretty
awesome
stuff.
A
B
Okay,
so
I'm
sure
everyone's
aware,
we've
been
working
on
many-to-many
for
most
of
the
ef
core
five
release,
and
this
has
been
a
work
of
a
lot
of
people
on
team
like
everybody
on
the
team
has
had
some
input
into
this.
I
want
to
especially
call
out
andrey
for
doing
all
the
model
building
andreas
are
like
metadata
expert.
You
know,
all
of
that
stuff
is,
is
his
work,
so
I
wouldn't
really
call
that
out
and
then
smit,
of
course,
always
the
the
query
stuff.
B
B
B
I
think
these
are
yesterday's
daily
builds
they're
currently
branded
as
600
alpha,
because
build
systems
are
hard
and
numbering
is
hard
and
numbers
get
wrong
and
difficult.
This
is
basically
the
tip
of
main,
which
is
you
know
what
master
branch
used
to
be.
So
this
is
essentially
5.0.
None
of
this
stuff
is
only
going
in
in
6-0,
so
you
can
still
use
the
daily
builds
and
even
though
it
says,
6-0
be
confident
that
that's
just
a
artifact
of
the
build
system
and
we're
still
working
five-o.
B
So
I
wanted
to
bring
that
up.
Let
me
now
show
you
the
very
simple
model
that
we're
working
with
here.
This
does
not
have
many
many
many
too
many,
yet
we're
going
to
add
many
to
many
in
a
minute.
I
have
two
entity
types,
trivially,
simple
community
and
person,
so
we're
going
to
join
these
together
with
a
community
person's
many
too
many
db
sets
for
them,
I'm
using
sql
lite,
just
because
it's
super
easy
and
we
can
and
it's
relational,
so
we
can
see
sql.
This
will
work
with
other
providers.
B
B
So,
let's
go
20
good.
That
looks
a
lot
better
thanks:
okay,
no
problem
yeah,
so
application
as
people
who
have
seen
me
demo
before
no,
I
love
console
applications.
You
know
grew
up
in
the
80s
and
that's
all
you
had
so
I
still
love
them.
Actually,
I
do
it
because
it
reduces
the
clutter
around
everything
else
which-
and
I
want
you
to
see
what
what's
important.
B
So
I
haven't
added
many
too
many
here,
but
I'm
creating
a
bunch
of
people
and
I'm
creating
a
bunch
of
communities
and
I'm
adding
these
to
the
database
and
I'm
saving
changes.
So
nothing,
nothing
really
interesting
there.
So,
let's
add
a
many-to-many
relationship
between
person
and
community.
So
I
can
do
that
simply
by
adding
a
navigation
property
from
person
to
from
community
to
a
collection
of
person
which
I'm
going
to
call
members,
and
then
I
can
add
one
in
the
opposite
direction.
B
Property,
and
basically
that
is
all
I
need
to
do-
to
implement
many
to
many,
so
I
haven't
added
another
model,
creating
anything,
I'm
not
adding
any
data
yet
we'll
do
that
in
a
minute.
But
if
I
run
this
now
and
look
at
the
sql
that's
generated
when
it
creates
the
database,
I'm
having
it
create
the
database
every
time
just
so,
we
can
see
what
happens
it's
creating
a
categories
table
as
we'd
expect
send
a
products
table
as
we
expect.
B
B
Okay,
that's
why
we
have
products
and
categories
which
is
not
what
we
were
expecting
to
see.
So
now
we
can
see,
we've
got
a
communities
table
and
a
people
table,
which
is
what
we'd
expect,
but
we've
also
got
a
community
person
table.
So
we've
detected
that
this
is
a
many-to-many
relationship.
We've
created
a
joint
table
silently
kind
of
behind
the
scenes,
almost
in
a
magic
way,
if
you
like
and
yeah.
That's
all
you
need
to
do
nothing
in
on
model,
creating
nothing
to
no
other
specifications,
so
we've
got
many
too
many
there.
B
So,
let's
look
at
how
that
you
know:
let's
use
it
now,
because
we're
not
using
it,
even
though
we've
got
it
so
in
my
little
application
here
I
am
going
to
put
some
associations
in
so
I
can
add
people
to
one
side
or
to
the
other
side.
You
know
it's
fine,
it'll
connect
them
up
either
way
and
and
then,
if
we
run
that
now
we'll
see
at
the
end
of
the
sql,
where
we're
adding
we're
inserting
that
values
into
the
many-to-many
table
automatically
and
we're
connecting
the
different
ids
together.
B
So
these
are
the
foreign
key
values
for
the
two
tables
that
also
forms
the
primary
key
for
our
many
many
table.
So
all
you
had
to
do.
There
was
add
the
entities
and
it
saves,
let's
also
look
at
retrieving
entities
from
the
database
with
many
too
many.
So
I've
got
a
little
bit
more
code
here
that
I'm
just
going
to
copy
in,
and
all
this
is
doing,
is
running
a
query
so
using
the
communities
db
set,
I'm
doing
include
directly
on
the
many
too
many
collections,
so
this
is
these
things
are
called.
B
B
I
can
use
this
in
any
queries
and
just
include
I
can
select
on,
and
I
can
you
know
all
those
things
so
true,
many
to
many
and
then
we've
got
some
code
here
that
just
print
it
out,
so
we
can
see
that
both
sides
are
being
loaded
correctly
and
that's
it.
So
if
this
was
ef6,
this
would
be
the
end
of
the
demo
and
we'd
all
go
home
and
say
wonderful.
Many
too
many
works,
however,
with
af6.
B
The
problem
is:
that,
literally,
is
all
you
can
do
if
you
want
to
change
anything
about
the
join
table.
If
you
want
to
query
for
the
join,
if
you
want
to
add
a
payload
you're
out
of
luck,
because
it's
really
kind
of
magic
under
the
covers
in
the
f6,
and
that
is
exactly
what
we
didn't
want
to
do
with
the
f
core.
A
B
B
Okay,
that's
a
somewhat
that
that
question
could
could
be
a
deep
question,
but
essentially
it's
a
three-stage
process.
Creating
an
instance
of
a
db
context
does
very
little
there's
very
little
work
and
that's
by
design,
so
just
creating
an
instance
is,
is
very
cheap
when
you
use
it
for
the
first
time,
then
the
first
time
it
does
that
it's
doing
some
model
initialization
and
things
like
that.
So
that
may
be
slow
warm-up
time.
We
have.
We
have
plans
for
that
in
the
future.
B
You
know
make
that
make
that
better
after
that,
after
it's
done
that,
then
each
time,
you
then
recreate
that
same
instance
and
use
it.
It's
pretty
low
overhead
to
do
that,
and
that's
why
we
recommend
creating
a
single
context.
Instance
per
unit
of
work,
because
it's
it's
it's
cheap
to
create
that
and
throw
it
away
to
the
on
model.
Creating
one
of
the
reasons
for
that
is.
The
model
is
cache
so
on
model
creating
by
default.
It's
only
called
once
and
then
we
cache
the
model.
B
So
that's
why
that
first
time
can
be
slower
after
that
all
modeling
creating
won't
be
called
every
time
now.
You
can
change
the
behavior
of
that
to
make
our
model
be
created
at
various.
You
know
various
different
times
depending
on.
If
you
change
certain
configurations,
but
in
general
you
need
to
keep
caching
the
model.
Otherwise
the
perf
won't
be
good.
B
C
B
That
was
the
end.
That's
the
end
right,
but
no,
we
built
we
built
af
core
functionally
as
a
collection
of
building
blocks,
on
which
we
then
layer,
high
level
features
like
many
too
many,
which
is
some
one
of
the
reasons
why
we
delayed
working
on
many
to
many,
because
we
really
needed
this
solid
foundation.
B
B
Okay,
so
this
is
a.
This
is
a
different.
This
is
a
different
demo
and
the
reason
I've
done
this
a
different
demo.
A
different
model
is
just
to
keep
the
concepts
here
separate
from
the
concepts
in
the
many
to
many.
So
we
don't
get
the
two
kind
of
things
confused,
but
the
the
things
that
we
learn
here
will
then
apply
to
the
many
to
many.
B
So
this
is
again
a
trivially
simple
product
category
demo
like
in
I'm
not
using
northwind,
but
it's
basically
northwind,
like
we've
all
seen
years
and
years
ago.
Well,
probably
not
all
of
us,
but
the
ones
that
have
been
around
have
seen
it
and
nothing
particularly
exciting
about
this,
except
I'm
not
using
navigation
properties,
which
I
will
get
into
in
a
little
bit.
Why
a
little
bit
later,
but
it's
actually
quite
interesting
as
well
to
see
that
you
don't
have
to
have
navigation
properties.
B
So,
for
example,
here
I'm
setting
up
a
relationship
in
products
and
category
and
I'm
telling
it
there's
no
navigation
product
that
way,
there's
no
inverse
navigation
product
that
way,
but
it's
still
a
one-to-many
relationship
and
ef
is
smart
enough
to
know,
then
that
this
is
going
to
be
my
foreign
key
because
it
matches
our
convention
for
foreign
key.
Even
though
there's
no
navigation
properties
defined,
so
that's
a
cool
little
thing
and
we'll
come
into
that
more
later.
B
Now
I
want
to
give
a
shout
out
to
colin
meek
here
who
was
on
the
ef
team.
When
I
first
started,
and
this
is
a
demo
he
used
to
do
and
for
being
from
britain,
I
loved
it.
So
we're
doing
it
again,
so
we've
got
two
categories:
we've
got
beverages
and
foods,
and
then
we've
got
two
products
called
marmite
and
bovrel.
Now
marmite
is
this
yeast
extract?
B
I
I
have
an
example
from
when
we
when
wendy
and
I
were
left
in
in
britain,
so
you
can
see
it's
this
little
mighty
thing
here.
I
don't
know
if
I
was
on
camera
there
or
not,
but
I
was
showing
it
if
I
was
anyway
marmite.
You
can
do
two
things
with
you
can
mix
it
with
hot
water
and
kind
of
drink.
It
like
a
broth
and
bottle
is
similar.
B
So
that's
a
little
history
of
the
marmite
poveral
scenario:
okay
back
to
the
code,
so
I'm
adding
adding
all
these
entities
to
the
you
know
to
the
context
to
start
tracking
them
and
then
save
changes.
There's
a
bit
of
there's
a
bit
of
code
here
that
I
won't
go
into
in
too
much
detail,
but
basically
what
this
is
doing
is
saying.
Actually
I
will
because
it's
really
interesting-
I'm
going
to
actually
run
this
and
show
you
what's
happening
here.
B
B
If
we
then
so,
we
can
then
set
these
on
both
marmite
and
borrow.
So
you
can
see
the
above
rule
if
we
look
at
it
now,
its
category
id
matches
this
temporary
value,
and
this
tells
ef.
Basically,
these
two
things
are
related.
Now,
when
we
save
changes,
we've
now
written
those
to
the
database
we've
rather
we've
inserted
the
entities
to
the
base.
We've
read
back
what
their
actual
values
are.
So
now
we've
updated
both
those
to
one,
because
that's
what
the
the
the
value
that
was
assigned
to
us
from
the
database.
B
So
this
is
allowing
us
to
relate
things
together
without
using
navigations,
which
is
an
and
useful
thing
to
know
about,
and
we'll
come
back
to
this
again
a
bit
later
and
then
I'm
just
doing
a
query
here:
updating
the
foreign
key
and
the
description
and
saving
changes.
Okay.
So
that's
my
that's
my
setup.
B
B
So
what
we
have
here,
I've
just
added
a
backing
dictionary
string
to
object.
So
this
is
where
somewhere
I
can
store
my
key
property
values
and
then
I've
exposed
an
index
of
property
in
ef
and
I've
said
okay,
I
want
to
take
a
property
name,
and
then
you
store
the
value
of
that
property
name
in
the
dictionary,
and
you
know
when
I
ask,
for
it
give
it
me
back
so
so
very,
very
simple
there.
B
Setting
up
so
I've
moved
to
the
nested
lambda
syntax,
but
otherwise
this
is
the
same.
This
is
what
we
had
before
and
then
I've
said
I
have
an
index
or
property
of
type
string,
which
is
called
description.
So
that's
how
we're
replacing
that's
basically
now
going
to
be
treated
the
same
way
as
the
actual
property
we
had
for
description
before
and
likewise
I
can
say
we
have
a
date
time.
Property
called
was
it
date
time?
No,
it
was
decimal,
I'm
getting
ahead
of
myself
called
price,
that's
right!
B
So
this
is
just
normal
c
sharp
syntax
here,
and
we
can
do
that
for
all
of
these,
of
which
there
are
not
very
many,
and
then
I
think,
maybe
down
here,
yeah
we're
updating
the
description.
We
need
to
do
it
here.
We
need
to
say:
okay
set
description,
okay,
so
if
we
run
this,
basically
it
behaves
hopefully
the
same
as
it
did
before.
I
don't
know
if
I
ran
it
before,
but
I
should
have
done
anyway.
B
You
can
see
that
we've
created
categories
and
products
like
we
were
supposed
to
and
we
still
have
a
description
and
a
price
field,
price
properties
in
the
table,
and
they
actually
are
correctly
typed,
sql,
lite
stores
date
times
or
rather
decimals
as
text,
although
the
experience
for
that
is
improving
a
lot
in
in
af,
core
5
is
still
limitation
of
sqlite's
type
system,
so
this
is,
if
we're
running
on
sql
server.
We
would
see
this
as
a
decimal
property
as
we'd
expect,
but
everything
else
has
worked
the
same.
B
We
still
insert
things
in
the
same
way
when
we
do
the
query
to
update
it's
the
same.
When
we,
you
know,
everything
is
basically
the
same,
so
we
haven't
really
changed
any
structure
and
that's
going
to
be
a
theme
throughout
these
product
category
marmite
demos
that
we're
not
really
changing
the
functionality
here,
we're
just
changing
the
way,
we're
doing
it.
Okay,
so
that's
basically
that
index
of
properties.
B
A
B
B
A
B
C
B
B
So
there
are
various
scenarios
that
may
become
apparent
as
we
go
through,
for
example,
property
bags
that
are
can
be
useful
on
index
or
properties,
they're
also
a
useful
way
of
extending
without
having
to
make
specific
changes
to
clr
types.
So
it's
not
a
complete
dynamic
model
solution
because
it
still
requires
configuration
in
the
f
model,
but
it's
one
of
the
things
that
allows
you
to
do
things
without
having
to
especially
explicitly
specify
a
clr
product
entity,
type
or
property
for
use
with
ef
cool
okay.
B
B
So
I'm
just
going
to
basically
replace
the
code
here
with
what
I
prepared
earlier,
which
is
the
same
thing.
They
both
still
have
id
and
name,
but
everything
else
on
each
of
these
is
being
stored
in
now,
in
a
dictionary
as
key
value
pairs
and
we're
going
to
have
to
you
know
similarly
update
down
here.
B
So
now
again,
I
haven't
changed
anything
all
I've
done
is
add
index
or
properties
to
both
of
these.
So
if
we
run
this
again,
we
can
see
that
everything
is
the
same.
We
create
the
same
tables
categories
and
products
with
the
same
profit
with
the
same
columns.
Rather
all
the
queries
and
everything
are
the
same
okay.
B
B
B
So
now
I've
broken
everything
right,
because
now
I
have
different
entity
types,
which
is
true,
but
I
can
make
all
of
this
work
again
and
you'll
see
why
this
is
important
to
many
too
many
as
we
go
forward.
So
first
thing
I
have
to
do
is
obviously
the
db
sets
are
now
of
named
entity
not
of
product
and
category,
and
this
now
no
longer
uniquely
identifies
an
entity
type
right.
B
This
is
why
we
call
a
shared
type
entity
type
because
we're
going
to
make
both
product
and
category
backed
by
the
same
entity
type,
and
we
do
this
in
db,
set
by
instead
of
using
a
getter
and
setter
on
here.
We
have
to
call
context
the
context
set
method
and
we
still
give
it
the
generic,
because
it's
still
a
generic
set
of
name
density,
but
then
inside
here,
because
this
is
a
named
entity,
we
actually
have
to
give
it
a
name.
B
B
B
These
have
to
match,
because
this
is
this
is
how
we've
now
defined
the
entity
type
in
our
model
by
this
name,
and
it
has
a
description
index
of
property,
and
then
we
have
a
shared
type
entity
type
product
and
it
has
a
description
price
and
a
category
id
property
and
we've
defined
the
navigation
without
relationships
in
the
same
way,
except
in
this
case.
We
have
to
tell
it
that
we're
going
to
this
shared
entity
type
and
there's
no
navigations.
B
B
Now,
of
course,
here
I
need
to
update
these.
Did
I
have
this
code?
No,
I
don't
think
I
have
this
code,
but
I
need
these
to
all
be
named
entity
and
you'll
notice
that
I
still
have
properties
on
named
entity.
So
name
is
still
a
regular
property.
It's
not
like
I've
changed
everything,
because
if
you
have
a
shared
type
entity
type
and
each
one
has
a
name,
then
you
can
just
use
that
in
a
normal
way.
So
again,
this
can
be
a
way
of
extending
and
I
think
that's
all.
B
B
That's
right!
It's
this
bit
so,
and
I've
even
got
a
note
for
it
in
my
notes.
So
let
me
tell
you
what
I
did
wrong
here
in
afcor.
Typically,
you
can
call
ad
range
to
add
a
heterogeneous
set
of
entity
types.
So
these
these
two,
you
know
in
the
in
the
first
code,
were
categories,
and
these
two
are
products
and
ef
can
typically
figure
out.
That's
those
ones
are
categories,
and
those
ones
are
products
because
they
know
what
the
clr
type
is
in
this
case,
we're
doing
that.
B
B
So
this
is
saying
the
key
category
id
is
not
present
in
the
dictionary
and
we
have
a
issue
on
the
backlog
to
make
this
better.
But
that's
because
in
this
case,
when
we
try
and
get
a
foreign
key
name
value
from
this,
if
it's
not
in
the
dictionary,
then
the
input
the
dictionary
implementation,
if
it
throws
now,
we
could
have
the
change
this.
So
we
say
check
if
it's
in
the
dictionary,
if
it
isn't
then
return
null.
B
If
it
is
then
return
the
value
and
that
would
work
fine,
I'm
not
doing
that
for
various
reasons,
partly
because
we
also
would
want
to
make
this
work
better
by
better
detecting
these
kinds
of
patterns
and
automatically
doing
that
for
you.
But
for
now
all
I'm
going
to
do
is
make
sure
that
I
set
the
foreign
key
values
to
no,
when
I'm
when
we're
adding
them
so
for
product
for
we're,
adding
so
not
on
the
categories
so
on
here,
I'm
going
to
do.
B
Okay,
now
we're
off
and
running
again
so
still
creating
category
tables
still
creating
a
product
table,
even
though
we've
only
got
one
clr
type.
Now,
I'm
still
creating
all
the
columns
like
we
worked
before
we're
still
inserting,
in
the
same
way,
querying
the
same
way
updating
the
same
way.
Everything
is
working
the
same.
B
C
B
B
Exactly
so,
I'm
showing
you
these
building
blocks
and
we're
going
to
switch
back
to
many
too
many
and
see
how
they're
actually
useful.
I
I
admit
that
showing
them
in
a
simple
way:
they
don't
look
useful,
but
in
in
working
through
this,
I
think
it's
easier
to
understand
them
split
out
separately,
rather
than
we're
all
put
back
together.
B
B
Times
so
yeah,
so
all
of
these
are
now
just
stirred
in
key
value
pairs
on
the
entity,
and
likewise
this
is
a
nice
example
of
how
this
still
works
in
query,
and
you
can
also
use
the
ef
property
syntax,
like
you
do,
for
shadow
properties
here,
and
that
will
work
just
fine,
but
I
don't
have
to.
I
can
just
write
index
properties
on
there
and
I
can
likewise
get
the
primary
key
value
from
the
property
back.
B
So
now
everything
is
being
accessed
to
index
or
properties.
So
then,
why
I
even
have
this
like
this
is
now
superfluous
right.
This
should
just
be
dictionary
string
to
object,
so
I'm
going
to
get
rid
of
named
entity
entirely
and
that
I'm
going
to
go
through
and
find
and
replace
all
my
name
density
with
dictionary
of
string
to
object.
B
B
These
the
same,
I
do
have
to
add,
because
I
didn't
yet
additional
configuration
for
the
indexer
properties
that
I
name
an
id,
so
I'm
I'm
going
to
put
that
there
and
that
there
I
also
made
the
name
required
just
as
a
show
you
that,
even
if
you're
setting
index
of
properties
and
it's
type
string,
even
though
this
is
nullable-
you
can
still
say-
create
it
non-nullable
in
the
database
and
make
sure
that's
required.
So
you
can
do
all
that
normal
configuration
that
you
would
do
on
other
properties.
B
Yes,
so
you
can
see
now
that
what
we've
done
is
we've
created
still
a
category
and
product
table,
but
they're
actually
backed
by
the
there's,
no
clr
type
at
all.
For
these
now
they're
just
the
built-in
dictionary
from
the
bcl,
and
this
is
what
we
call
property
bag
entity
types
where
you're
just
basically
using
dictionary
string
to
object
for
your
entity
types,
and
you
can
see
that
I've
evolved
the
code
through
those
steps
like
so
the
property
bag
entity
types
are
shared
type
entity,
types
that
build
on
index
of
properties.
B
C
B
You
can
use
another
type
because,
basically,
all
a
property
bag
is
composition
over
shared
type
entity,
type
and
indexer
properties.
At
the
moment,
dictionary
string
to
object
is
set
up
by
default
to
be
a
shared
type
entity
type.
You
have
to
do
a
little
bit
more
work
occasionally
to
to
do
something
other
than
that,
but
that's
part
of
something
that
we're
gonna
improve.
C
B
No,
it
doesn't,
but
we
have
things
like
the
ef
property
method
that
allows
you
to.
You
know,
do
certain
level
of
dynamic.
However,
if
you
want
to
go
yeah
so
so
diet,
so
I'm
not
gonna.
I
don't
want
to
claim
that
what
we
have
here
is
full
support
for
completely
dynamic
models
in
ef
core,
because
that's
not
the
case,
but
it
allows
you
to
do
some
combinations
of
dynamic
and
non-dynamic.
C
B
Yes,
okay,
so
let's
see,
let
me
go
to
back
to
many
to
many
here
and
what
I'm
going
to
do
is
now
I'm
going
to
put
a
break
point
right
after
we
have
created
the
model
and
I'm
going
to
run.
Hopefully
this
will
run
in
the
debugger
and
have
it
right
this
time.
Okay,
so
then,
hopefully
everybody
knows
this,
but
I'm
going
to
show
you
that
we
have
debug
views
in
ef
core
five
and
we've
improved
them
a
lot,
even
though
this
one
was
there
before.
B
So
this
is
now
showing
me
the
model
that
I've
built
with
af,
and
you
can
see
that
I
have
a
community
type
which
is
as
expected,
and
I
have
a
person
type
which
is
as
expected
because
we
define
these
two.
But
now,
when
I
look,
I
actually
have
a
community
person
entity
type
in
my
model,
so
this
is
the
backing
table.
This
is
the
join
type
and
it's
actually
clr
type
is
dictionary
string
to
object.
B
So
this
isn't
actually
changing
my
model
at
all.
I'm
just
doing
explicitly
what
ef
is
doing
by
convention
and
if
I
run
this
we
can
see
at
the
end
everything
comes
out
the
same.
We
haven't
actually
changed
anything
okay,
so
we
can
actually
even
be
more
explicit
than
that
because
in
this
case
you'll
notice,
I
still
don't
mention
the
join
table
at
all.
I'm
just
saying
I'm
just
saying
these
are
many
to
many.
B
So
in
this
case
now
I've
got
the
same
many
too
many,
but
I'm
doing
this
using
entity
and
what
this
means
is
use
this
entity
type
for
your
join
table,
and
we
know
this
is
a
dictionary
string
to
object.
It's
a
property
back
into
type,
I'm
going
to
change
this
to
other
things
later
on,
and
we
have
to
give
it
a
name
because
shared
type
entity
type
as
we
show
in
the
other.
B
In
the
other
case,
with
products
and
category,
this
doesn't
define
the
entity
type
anymore,
so
we
need
a
name
for
it
and
then
this
is
basically
we'll
come
back
to
this
later,
but
this
is
basically
saying
with
this
join
table.
This
is
the
relationship
between
it
and
the
two
sides
of
the
many
to
many
and
in
the
same
way,
that
we
set
up
a
relationship
in
that
example,
without
any
navigation
properties,
we're
not
putting
any
navigation
properties
in
here
too,
however,
we'll
come
back
later,
we
will
have
navigation
properties
there.
B
So
again,
I
haven't
changed
anything
now.
All
I've
done
here
is
explicitly
configure
what
ef
is
configuring?
Always,
however,
this
is
finally
where
it
starts
to
get
cool.
I
think,
if
you
didn't
think
it
was
cool
already,
and
that
is
I
can
now
chain
onto
this.
I
don't
have
to
do
it
this
way.
I
could
do
this
in
a
separate
call,
but
I'm
actually
saying
actually
add
another
property
to
my
join
table.
Add
annoying
property
to
my
join
entity
type,
and
this
is
what's
typically
called
a
payload
and
you
will
heard
well.
B
Remember
since
and
again
this
is
equal
light,
so
it's
a
text
column,
but
it's
really
date
time
and
if
we
look
at
the
inserts
into
the
join
table,
obviously
it's
not
particularly
useful
right
now,
because
all
we're
doing
is
inserting
the
default
time
because
we're
not
setting
it
to
anything.
So
there
are
various
ways
that
you
could
set
this
properly.
B
I'm
going
to
show
one
first
and
then
I
do
for
one
second,
the
first
one
I'm
going
to
show
is
overriding,
save
changes.
So
we
can
override
save
changes
or
in
ef
core
5.
There's
save
changes,
interceptor
that
you
can
use,
or
there
are
saving
changes.
Events
that
you
can
hook
into,
so
you
don't
have
to
overwrite
save
changes,
but
it's
the
same
concept
either
way
and
in
overriding
save
changes.
B
All
I'm
doing
is
looking
for
entries
that
we're
tracking
I'm
telling
them
that
this,
because
I
know
that's
what
I've
configured
my
joint
table
as
now,
even
though
by
convention
we
use
dictionary
strings
object
for
the
join
entity
type
right
now
we
are
looking
optimizations
where,
for
example,
if
you
just
have
two
foreign
key
properties
that
are
in
dictionary
string
objects
is
overkill.
So
we'll
want
to
change
that.
B
So
that's
just
a
little
little
aside
to
be
aware
of
so
what
I'm
doing
is
saying
give
me
those
entities
find
the
ones
that
are
added.
I
we're
going
to
insert
them
and
set
the
current
time
to
the
client
current
time
value.
So
if
we
run
this,
we
should
see
that
now
we're
actually
inserting
appropriate
times
in
there.
Of
course,
normally
you
don't
want
to
do.
Client-Side
timestamp!
You
want
to
do
a
server-side
timestamp.
B
That's
super
easy!
So,
instead
of
instead
of
just
okay,
yes,
here
we
go
instead
of
overriding
save
changes,
I'm
just
gonna
say:
okay
in
the
database.
This
has
default
value
constraint
on
the
column
with
this
sql,
which
in
sql
lite,
will
give
you
the
current
timestamp
so
now,
you'll
see
that
the
inserts
we
do
are
different,
because
now
what
we're
we're
not
actually
passing
in
any
date,
but
we're
selecting
back,
remember
since
that's
been
set
by
the
by
the
database
and
putting
that
propagating
that
back
into
our
entity
types.
B
So
we've
now
basically
said
now:
whenever
a
member
is
created,
so
whenever
you
associate
a
join
person
with
a
community
and
say
they
are
now
a
member,
then
that
joint
table
is
going
to
get
the
date
at
which
that
was
made
in
the
database,
and
why
would
we
do
that
if
we
didn't
want
to
look
for
it?
So
let's
look
at
that
data,
so
I'm
going
to
add
this
to
the
end
of
where
I'm
printing
stuff
out
here.
B
So
what
am
I
doing
here?
So
in
the
same
way,
in
the
that
we
saw
in
the
marmite
demo,
I
can
create
a
db
set
of
this
shared
type
entity
type.
I
can
say
this
is
the
one
I
want
and
then
I
could
just
get
all
the
entities
out.
I
can
just
query
for
it,
so
I'm
just
querying
for
the
join
table
now,
even
though
there
isn't
any
entity
type
representing
that
other
than
this
property.
B
C
B
B
So,
essentially,
once
you're
going
down
this
path,
you
may
get
to
the
point
where
which
is
essentially
where
we
are
now,
where
we're
saying.
Okay,
this
being
a
sorry,
I'm
fine,
this
being
a
trying
to
find
my
where's
my
model
building
there.
It
is
instead
of
this
being
a
property
bag.
We
maybe
we
should
actually
have
our
own
entity
type
for
it.
B
So
let
me
create
that.
Let
me
create
a
join
entity
type
so
now,
you're
saying
oh,
this
looks
like
this
looks
like
ef
core
three
right.
This
isn't
any
good
right!
It's
not
because,
even
though
I'm
going
to
change
this
to
say,
use
a
join
type
so
person
community
here
do
I
have
the
configuration
written
for
this?
Yes,.
B
So
I
don't
have
to
I'm
not
really
changing
very
much
here,
but
what
I'm
doing
is
saying:
stop
using
a
shared
type
entity
type,
stop
using
a
property
bag,
stop
using
the
index
of
properties.
Use
this,
and
this
will
all
work,
and
all
I've
done
is
change
this
here.
The
code
down
here
now
will
need
to
change.
To
say
you
know,
get
me
the
stuff
out,
get
me
the
stuff
out
of
not
a
dictionary
which
we'll
do
in
a
minute,
but
basically
at
this
point.
B
Hopefully
this
will
just
run
and
you
can
see
that
we're
still
using
it
as
a
many-to-many.
Everything
is
nothing's
changed
in
the
database
and
what
that
means
and
nothing's
really
changed
on
the
model.
So
that
means
this
code
here,
where
I'm
adding
people
as
many
to
many
I'm
not
now
going
and
saying
I've
got
to
create
a
join
table
entity
for
that
and
add
those
it's
like.
B
B
So
I
could
in
here
also
add
a
collection
of
person
community
and
leave
this
one
there
as
well
and
likewise
there.
So
you
can
have
both
the
navigations
that
go
to
and
from
your
join
entity
types
and
the
navigations
that
skip
over
the
join
entity
types
and
just
behave
like
a
many-to-many
and
those
can
co-exist
at
the
same
time
and
that's
really
important
for
two
two
scenarios:
one
is:
I've
got
existing
code
that
I've
already
got
joined
into
types
map
like
this,
and
I
want
to
add
many
to
men
into
it.
B
You
don't
have
to
throw
all
of
that
away.
Most
of
your
business
logic
can
stay
the
same.
You
can
incrementally
use
many
too
many,
as
you
update
it
very
composers.
Together,
you
will
have
to
change
some
of
your
mapping,
but
it's
a
lot.
It's
a
relatively
easy
transition
and
then
the
other
scenario,
which
is
what
I've
been
showing
where
you
start
off
thinking
this
isn't
many
20.
All
I
need
is
many
too
many,
and
then
you
realize
you
actually
need
more
business
logic
associated
with
that.
B
So
then
you
can
evolve
it
into
adding
these
things,
so
I've
added
navigation
properties.
Here
now
we
can
come
back
to
this
configuration
of
many
to
many
and
where
I
was
doing
it
without
navigation
properties.
Here
I
could
actually
start
saying.
Okay,
this
has
a
navigation
property
and
this
one
has
a
navigation
property.
Now
I
don't
need
the
the
explicit
generic
types,
because
it's
inferred
from
these
now
and
then
so
now
we
have
that
and
then,
when
we
go
down
to
our
code,
to
query.
B
Instead
of
just
printing
out
the
ids,
we
can
now
use
those
navigation
properties
to
actually
go
back
and
say:
oh
no,
I
haven't
done
it
yet.
I
need
to
edit
that
so
this
is
basically
all
we've
done.
There
is
change
it
to
person
community,
so
we're
querying
that
set
instead
of
the
property
bag
type
and
then
I'm
still
printing
out
the
id
there.
But
I
can
go
now.
I've
got
this
navigation
property,
I
can
just
say
member
name
and
on
here
I
can
say.
B
Whatever
I
called
that
member,
no,
not
member,
so
that's
member
name,
so
that
would
be
community
no
memberships
membership,
that's
right,
I'll,
remember,
eventually,
membership
name,
and
obviously
we
keep
doing
memberships
like
that.
So
if
I
run
this
now
we
should
actually
get
nice
code.
That's
querying
the
join
table
and
giving
us
data
that
arthur
was
a
member
of
microsoft
ease
since
just
now,
apparently
so
yeah.
That
is
basically
it
that
shows.
So
what
we've
shown
here
is
how
you
can
do
many
too
many
fully
by
convention
just
like
in
ef6.
B
Essentially,
you
don't
have
to
worry
about
anything.
That's
going
on.
You
don't
have
to
know
about
anything.
That's
going
on
under
the
covers,
but
under
the
covers
it's
being
built
from
these
building
blocks
that
allow
you
to
then
evolve
your
model
to
do
more
complex
things.
If
the
conventions
don't
quite
work
for
you,
because
you
need
something
different,
I
want
one
thing
I
forgot
to
mention
on
the
marmite
that
is
relevant
here
and
I
want
to.
B
I
want
to
come
back
to
it,
so
I
wrote
I
showed
you
this
code
and
we
debugged
it
at
the
beginning
about
setting
foreign
key
values,
and
you
notice
that
this
code
didn't
change
throughout
the
whole
of
the
demos.
I
changed
this
thing
from
for
from
a
to
use
property
bag,
entity,
types
to
sorry,
to
use
index
of
properties,
to
use,
share
type
entity
types
and
then
be
a
property
bag.
All
of
these
apis
that
ef
has
for
accessing
metadata
and
values,
and
your
model
and
your
tracked
entities
in
a
uniform
way.
A
B
A
A
C
B
Property
bag
entity
types
and
there
are
various
ways
to
do
that.
Various
thing
uses
for
that
in
terms
of
dynams
or
pseudo-dynamically,
adding
things
to
your
your
types,
I'm
being
careful
not
to
oversell
it,
because
it
really
is
useful
for
extensibility
and
things
like
that,
but
also
they're
used
under
the
covers
for
many
too
many.
So
there
you
go
that's
a
use
case
for
shared
type
entity
types.
B
News
as
it
so,
we've
made
a
bunch
of
improvements
for
migrations
for
5.0
there's,
not
much
change
in
the
seeding
in
the
seeding
world.
I
don't
think
sequel,
sequel
light.
Now
we
now
support
table
rebuilds
and
migrations,
which
is,
which
is
a
big
thing
that
enables
migrations
to
be
much
more
usable
in
sql
light
and
and
we're
continuing
to
look
at
experiences
there.
Do
you
want
to
add
anything
bryce.
C
A
A
Yeah,
I'm
not
sure
either
I
think
maybe
looking
for
actual
join
types.
Maybe
I
don't
know
I'll.
Let
martin
type
out
his
question
again,
if
maybe
for
some
more
clarity
and
here's
a
cheer
out
to
bryce
for
all
the
work
on
sql
light
from
julie,
thanks,
julie
and
then
here's
a
question.
Does
ef
5
work
with
nosql
like
mongodb,
and
the
answer
is
no
not
like
mongodb
but
yes,
like
cosmos
db,
it
will
work
with
that.
We
have
a
cosmos
db
provider.