►
Description
As we keep improving Entity Framework Core, we love to show you what we are working on to get early feedback and improve our designs. We have a number of great things coming, like the Cosmos DB provider (no longer just a prototype!) and spatial support. We will spend 45 minutes showing demos!
A
B
A
So
some
of
the
features
we
are
talking
about
today
are
things
that
he
wrote,
and
so
we
can
ask
MIT
some
questions
about
that.
We
are
going
to
talk
about
until
framework
code
to
point
to
a.
We
are
very
happy
that
we
ship
the
second
preview
of
2.2.
This
morning
we
we
published
a
blog
post
with
a
number
of
getting
started,
a
demos
of
how
to
start
playing
with
the
new
features,
and
we
are
going
to
show
some
of
them
today.
So
2.2
is
a
relatively
small
release
for
us
a
compared
to
2.1.
A
When
we
did
last
year,
the
presentation
internet
comes,
we
actually
had
lots
of
demos
and
we
had
to
choose
which
ones
not
to
show,
but
this
year
we
have
like
a
smaller
number
of
new
features.
Some
of
the
features
are
really
large
for
us,
but
a
mostly
2.2
is
a
is
a
releasing
which
we
are
going
to
have
few
features
and
many
bug
fixes,
and
we
are
already
working
on
3.0
size
went
with
an
extra
list.
So,
let's
start
with
the
first
feature.
A
So
our
first
demo
is
about
a
collections
of
own
types.
The
idea
with
own
types
or
own
entities
is
that
you
can
represent
in
the
AF
model
a
stronger
relationship
that
just
a
normal
relationship
in
a
database.
You
can
say:
ok
this
entity,
for
instance.
The
canonical
example
is
address,
is
owned
by
a
customer.
That
means
that
you
cannot
have
the
address
just
exists
independently
of
the
customer,
and
when
you
want
to
manipulate
data
on
the
address,
you
need
to
actually
load
the
customer
and
basically
go
through
the
customer
tool
to
do
anything.
A
B
Here
we
have
demo
about
so.
Basically,
let's
doing
some
quick
recap
here
about
like
own
types,
which
was
introducing
to
zero.
So
we
have
our
customer
entity
which
has
work
address
and
home
address,
as
you
can
see
here,
address
is
an
own
entity.
It
does
not
have
any
primary
key
defined
it
just
different
string
values
in
order
to
use
own
type.
We
use
like
owns
one
API
and
specified
reference
navigation.
So
in
this
case,
work
address
and
home
address
both
are
stored
as
own
entities.
B
A
So
we
one
thing
I
wanted
to
mention
that
I
forgot
is
a
when
you
do
ownership
in
entities
that
three
are
some
automatic
behaviors
on
the
model.
That's
one
of
the
uses
of
it.
For
instance,
you
don't
need
to
write,
include
it
to
get
the
instances
of
own
types
they
get
included
automatically
in
the
resource
of
queries.
So.
B
B
A
So
if
you're
familiar
with
antifungals
6,
we
have
this
feature
called
complex
types,
and
own
types
are
kind
of
a
superset
of
what
complex
types
could
do.
So
one
of
the
things
is
basically,
this
by
convention
just
store
the
data
of
a
complex
type
in
the
same
table
as
the
complex
type
you're
running
into
issues
with
yeah.
B
Just
go
forward
with
the
demo,
so
in
this
example,
with
own
type,
with
reference
navigation,
we
have
created
a
single
table.
That's
like
what
is
the
relational
behavior
here
now
moving
forward
to
moving
forward
like
let's
convert
this
to
an
own
collection,
so
suppose
here
we
have
work,
address
and
home
address.
If
we
want
to
store
more
addresses
than
this,
then
or
it
is
an
unbounded
set,
then
what
we
need
here
is
a
list
of
navigations.
So
first
we
will
add
a
list
of
navigations
and
remove
work
address
and
home
address
navigations.
B
B
B
So
with
this
configuration,
the
only
things
we
need
to
change
now
is
the
data
setting
part
which
we
were
adding
through
reference
navigation.
So
we
will
just
move
it
to
collection
now
so
with
this.
So
for
now
we
have
configured
one-to-many
relationship
to
use
ownership.
This
is
going
to
this
is
very
similar
to
what
it
would
be
a
normal
one
to
any
relationship
in
relational
database.
B
The
behavioral
difference
comes
in
what
Diego
mentioned
earlier
is
like
automated
include
and
address
cannot
exist
without
customer
and
you
have
to
store
together
and
all
those
things
in
terms
of
like
database
structure.
It
is
still
going
to
be
same
so
if
we
recreate
the
database,
so
here
you
can
see,
we
have
customers
table
and
address
table.
B
A
From
the
perspective
of
a
user
of
year
6,
you
can
see
now
basically
what
the
F
chord
ask
equivalent
of
having
collections
of
complex
types,
which
is
a
feature
that
was
requested
for
year
six,
but
we
never
supported.
Also,
this
I
think
brings
back
the
the
real
reason
we
are
having
this
feature.
If
you
want
to
talk
about
that,
so.
B
Then
the
real
reason
we
are
adding
this
feature
is
like
we
are:
writing
a
cosmos
DB
provider
for
EF
core.
So,
as
you
know
that
cosmos
TB
is
a
non
relational
database,
the
way
data
is
stored
is
a
it's
a
JSON
document
for
a
JSON
document.
It
is
very
natural
to
have
nested
elements,
so
each
JSON
document
can
have
another
JSON
inside
as
a
nested.
It
could
be
single
entity
like
a
dictionary
or
it
could
be
an
array
as
a
collection,
so
ownership
is
for
us.
B
That's
what
we
have
decided
that
like
we
will
utilize
the
ownership
to
decide
if
this
should
be
like
nested
resource,
and
it
should
be
married
in
the
same.
Json
therefore
like
that
was
the
main
reason,
because
it
is
very
required
to
have
like
collection
of
entities
nested
inside
in
the
JSON
document.
Therefore,
like
we
are
implementing
own
collections,
along
with
own
reference,
navigations
yeah.
A
Yeah,
so
so,
basically,
the
it
gives
you
a
uniform
way
to
talk
about
ownership
across
different
providers.
The
implementation
is
going
to
be
different
if
it
is
a
relational
database,
in
which
case
is
going
to
be
storing
a
separate
table
or
if
it
is
a
document
database,
in
which
case
it's
going
to
be
stored,
embedded
in
the
same
document.
A
Okay,
so
the
next
demo
we
are
going
to
talk
about
is
our
spatial
extension.
So
in
preview
to
that
we
shipped
this
morning,
we
have
a
special
extensions
for
the
EF
core
provider
for
sequel
server
and
also
we
enable
the
functionality
with
the
in-memory
provider
and
the
plan
is
for
2.2
preview
3
to
also
enable
it
for
sequel
Lite.
A
We
we
are
doing
this
because
many
customers
have
requested
that
we
have
this
feature
in
EF
core,
it's
a
very
popular
request
and
it
enables
working
with
data
and
with
databases
that
already
have
the
functionality
that
basically
can
store
data.
That
is
spatial
and
can
also
compute
functions
on
the
database
and
index
data
is
spatial
and
make
it
efficient
to
work
with
it
and
to
do
things
like
give
me
all
the
roles
that
belonging
at
the
instance
within
this
radius,
or
things
like
that.
So
we
are
enabling
that
in
in
link
as
well.
A
So
the
way
it
works
is
basically
we
we
went
looking
for
a
library
that
we
could
use,
for.
That
was
a
dotnet
library
that
we
could
use
in
dotnet
core
and
on
that
framework
that
had
special
functionality
and
we
found
a
NTS.
There
is
a
net
topology
suit
is
a
library
that
there
is
another
provider,
the
provider,
for
a
possible
sequel
that
is
already
using
to
implement
some
of
this
functionality
and
is
a
popular
and
and
decent
library.
We
believe
that
it
works
very
well.
A
So
what
we
are
supporting
with
this
extension
is
to
say
you
create
an
entity.
You
put
a
property
on
that
entity
that
uses
one
of
the
types
from
this
library.
Let's
say
that
you
want
to
use
a
point
or
a
line
or
a
polygon
property,
and
now
we
have
the
ability
to
map
that
to
special
types
on
the
database.
So
let's
say
that
you
are
using
a
geometric
column
on
sequel
server
and
you
want
to
store
points
in
that
and
then
perform
some
computations.
A
Then
EF
through
this
library
is
going
to
enable
that
to
be
mapped.
And
then,
whenever
you
write
in
a
linked
query,
some
computation
on
this
type,
for
instance,
you
want
to
compute
the
distance
between
this
type
and
another
type.
We
also
have
the
ability
to
look
at
that
in
the
expression
and
translate
it
to
the
corresponding
function
in
sequence.
So
we
want
to
show
that
in
the
demo,
so.
B
Here
we
have
a
measurement
class
which
is
with
what
we
are
going
to
use
an
entity
so
measurement
basically
records
time
and
location
and
temperature
at
that
location
at
given
time.
So
we
have
set
up
our
sensor
context
to
use
measurements
and
persist
measurement
entity
in
order
to
so
in
our
measurement
entity.
We
have
a
point
which
is
location
which
is
of
type
point
in
order
to
save
point
to
server.
We
need
to
use
a
new
package
which
is
called
my
of
any
framework
or
sequel
server,
dotnet
topology
suit.
B
With
this
package
there
is
an
extension
method
which
comes
into
picture,
which
is
like
use
neck,
topology
suit.
So
with
this,
your
sensor
context
is
ready
to
use
types
which
are
based
on
special,
so
we
are
going
to
store
some
of
the
measurement
to
server
and
we
are
going
to
run
query
against
it.
So,
let's
just
first
set
up
our
database
so.
B
B
So
we
stored
point
of
with
X&Y
coordinates
and
they
got
converted
to
an
geometries
type
and
stored
as
a
blob
on
the
server.
Now,
with
this
like
yeah,
we
have
saved
data
to
server.
Now
we
let
go
and
run
a
query
over
it,
so
we
have
our
current
location
as
0
0.
We
want
to
find
out
all
the
measurements
which
are
less
than
2.5
distance
away
from
the
current
location
and
sort
them
by
the
distance
from
current
location.
B
So
when
we
run
this
query
to
server,
basically,
we
get
4
result
out
of
it
in
the
sorted
order,
based
on
the
distance.
The.
If
you
look
at
the
query
we
run,
it
is
having
the
where
clause,
which
using
St
distance
function,
which
is
basically
like
what
distance
in
link
would
map
to
on
sequel
server
functions
in
our
current
provider,
so,
basically
with
neck
topology
suit
package
we
have
included,
is
it
allows
you
to
map
type
coming
from
neck
topology
suit,
like
relevant
sequel
server
types
along
with?
It
also
includes
translation
for
link.
B
A
We
have
some
limitations,
though,
in
the
current
implementation
that
we
are
that
we
ship
as
part
of
previa
to
for
instance,
that
is
a
type
that
is
also
very
popular
in
sequencer,
that
is,
geography
that
is
very
similar
to
geometry,
but
optimized
for
scenarios
that
involve
like
points
on
the
earth
or
or
similar
scenarios,
so
that
doesn't
work
still
very
well
or
at
all.
You
could
say
on
on
pivot,
too,
but
we
are
planning
on
importing
for
the
next
preview.
A
A
So
we
are
going
to
show
then
another
smaller
feature
that
we're
working
on
that's
called
query
tags,
so
cool
attacks
is
a
feature
that
we
thought
about
a
long
time
ago,
but
we
we
hadn't,
implemented
it.
Yet
people,
often
that
write
large
applications
that
generate
lots
of
queries
to
the
database.
They
often
need
to
correlate
a
sorry
queries
that
they
find
in
their
logs
with
queries
that
are
in
the
code.
A
That
may
happen
if
you
are
doing
like
the
post-mortem
of
some
some
incident
that
you
have
with
your
database
performance
problems
that
you
have
with
your
database
and
qualitex,
give
you
the
ability
to
flow
a
string,
the
piece
of
data
that
uniquely
identifies
equity
so
that
it
also
gets
emitted
on
the
on
the
sequel
and
we
emitted
us
a
comment.
So,
let's
show
how
the
API
looks
like
so.
B
B
B
But,
as
you
can
see
in
the
logs
here,
the
DB
command,
which
executed
it
has
a
comment
with
EF
course
prefix.
This
is
my
special
query
which
what
we
have
written
in
the
tag
so
using
with
tag
basically
like
we
are
going
to
it
print
out.
This
comment,
which
allows
correlation.
It
is
also
useful
for
the
scenario
like
collection
include,
in
which
case
EF
core
is
going
to
generate
multiple
queries
to
avoid
redundant
data
being
fetched
from
the
server.
In
that
case,
a
single
link
very
generating
multiple
select
expression.
You
can
correlate
those
scenarios
also.
A
We
are
going
to
show
the
cosmos
till
you
provided
that
we
have
been
working
on
now.
I
want
to
to
start
saying,
we
have
been
showing
a
cosmos
to
be
provided
prototype
that
we
put
together
as
a
proof
of
concept
for
some
time.
I
believe
that
if
I'm
not
mistaken
on
the
on
the
odd
night,
conf
talk
that
we
did
last
year,
we
showed
that
prototype.
The
big
the
biggest
difference
now
is
that
the
the
code
that
we
are
going
to
show
is
for
real.
A
It's
basically
the
code
that
we
plan
on
keep
working
on
and
improving
it's
a
real
deal.
It's
not
a
prototype
anymore.
The
prototype
bug
was
very
useful
to
get
some
feedback
from
you.
The
main
piece
of
feedback
that
we
got
was
basically
that
you
see
the
value
in
having
the
ability
to
use
the
F
chord
API
to
target
cosmos
TV
as
an
application
database,
people
that
are
used
to
dotnet.
They
are
used
to
how
data
access
works
in
dotnet
and
are
using
here
for
have
been
using
here.
A
For
some
time
they
see
value
in
being
able
to
now
just
target
cosmos
TV
as
a
different
option.
Of
course,
cosmos
TV
be
in
a
no
sequel
database
having
its
own
benefits
its
own,
like
really
fantastic
characteristics.
It's
going
to
give
you
different
different
values,
so
you
are
still
going
to
probably
want
to
do
things
directly
on
cosmos,
CD
that
you
would
do
differently,
but
at
least
you
have
like
some
uniformity
on
how
you
deal
with
it
from
the
EF
core
API.
Let's
look
at
it
so.
B
Here
we
have
basically
for
the
purpose
of
demo.
We
have
a
blog
and
post
model,
so
each
block
contains
contains
a
list
of
post.
For
this
demo.
We
are
going
to
use
Azure
cosmos
DB
new
later,
which
is
basically
a
local
host
based,
emulated,
Azure,
provides
to
test
and
develop
cosmos,
AB,
star,
gating,
cosmos
DB.
So
in
order
to
use
cosmos
in
DB,
basically,
the
API
is
like
used,
cosmos
sequel,
which
takes
endpoints
authentication
token
and
database
name.
B
There
is
also
planned
from
like,
as
your
cosmos
DB
team,
to
have
a
API
based
on
connection
string,
which
combines
all
this
thing
into
one,
instead
of
specifying
them
separately
once
it
is
enabled
on
that
side.
We
also
plan
to
add
first-class
support
for
that,
so
you
could
provide
connection
string
just
like
you
do,
like
all
other
relational
databases,
so
in
our
basically
blocking
context,
we
have
setup
to
use
two
cosmos
sequel.
B
B
Next
we
are
going
to
do
is
after
creating
database,
we
are
going
to
add
a
bunch
of
records
in
it,
so
we
here
we
have
a
blog
which
has
to
post
inside
it
and
two
other
blocks
without
any
post,
so
total
five
records,
so
we
save
using
Save
Changes
async.
We
saved
those
records
to
cosmos
DB.
If
we
go
back
here
and
look
at
the
document,
so
we
have
five
documents
in
our
unicorn
collection.
So
as
you
can,
as
you
would
notice
here,
that,
like
blog
and
post,
both
are
stored
in
the
same
collection.
B
So
this
is
one
of
the
things
which
we
change
from
our
prototype
last
year,
so
in
our
prototype
model
or
the
demo
we
showed
previously,
every
inheritance
hierarchy
of
entity
type
would
map
to
its
own
collection.
This
is
generally
like
what
we
follow
in
relational
model
that
every
hierarchy
goes
to
own
table.
The
feedback
we
got
was
mainly
big
based
on
the
pricing
model
of
Cosmos
DB,
so
each
collection
in
cosmos
DB
has
a
fixed
minimum
amount
of
throughput
quota
and
storage
quota
assigned
to
it.
B
So
if
you
have
a
collection
which
does
not
have
many
records
for
like
low
utilization
rate,
then
it
is
going
to
cost
you
a
lot
of
money,
even
though
you
are
not
using
it.
Based
on
that
feedback
and
like
what
customer
told
us,
we
decide
that
it
is
like,
in
the
best
interest
of
customer,
that
likes
to
store
all
the
documents
in
a
single
collection.
There
is
a.
B
We
also
have
built
this
in
a
way
that
customer
can
decide
how
they
want
to
store,
or
they
want
to
store
across
multiple
collections,
or
they
want
to
store
everything
in
same
collection.
There
is
a
way
to
configure
it
in
order
to
store
multiple
entities
into
same
collection.
What
we
are
also
doing
is
like
we
are
going
to
introduce
a
discriminated
column.
So
in
this
document,
as
you
can
see,
a
discriminator
name
is
blog
same
for
a
post.
The
discriminative
would
have
value
of
post.
B
That
is
what
we
are
going
to
use
to
identify
which
kind
of
entity
it
is
so
when
we
are
materializing
back.
We
know
which
data
to
read
from
another
thing
here
is
like
the
ID
is
the
ID
property
in
a
JSON
document
on
cosmos,
DB
side,
it's
a
string
of
250
character
max
for
a
user
application.
The
ID
could
be
like
a
different
variety
of
things.
B
Furthermore,
when
there
are
multiple
entities
in
the
same
collection,
those
ID
could
also
clash
with
each
other
if
they
have
same
value,
which
is
not
an
incorrect
data,
since
those
anti
types
are
like
totally
different
type,
but
it's
just
how
it
is
mapped
to
database.
It
could
cause
an
error
because
of
that,
what
we
have
decided
to
do
is
like
ID
is
what
we
ought
to
generate
automatically
and
the
primary
could
be
stored
separately.
So
primary
key
is
unique
and
it
also
will
be
treated
as
such.
B
An
AF
core
model,
but
it
won't
be
enforced
on
this
side
of
database
strictly
and
database
will
be
using
ID,
which
is
like
auto
generated
by
the
server
so
preview.
2
currently
has
this
limitation.
So,
while
using
preview
to
package,
you
may
need
to
provide
your
own
ID,
which
don't
clash
with
each
other
across
different
entities,
but
that
is
what
we
have
fixed
in
our
nightly
bill
already
so
I've
just.
A
One
quad
little
that
I
don't
know
if
you
remember
this,
but
the
the
reason
we
we
started.
The
discussion
on
just
mapping
by
default
to
the
same
collection
started
because
of
somebody
posting
the
feedback
to
channel
9
after
we
did
the
demo
of
the
prototype.
So
we
hope
that
that
people
are
going
to
start
giving
us
more
feedback.
We
actually
need
that
feedback.
In
this
case,
this
feature
is
is
huge.
The
special
extensions
are
also
big
and
normally
we
need.
A
We
need
some
time
to
mature
features
like
that,
to
make
sure
that
when
we
shipped
them
for
the
first
time
is
something
that
we
can
keep
evolving
without
too
many
breaking
changes
and
that
we
get
the
design
right.
So
the
more
feedback
that
you
can
give
us
the
more
chances
we
have
of
actually
getting
it
right
on
the
first
shot
on
the
first
release
and
the
more
chances
we
have
of
actually
including
these
features
in
our
TM
of
2.2,
so
welcome
all
the
feedback
so.
B
B
So
in
order
to
query
basically,
we
are
going
to
run
a
sequel
query,
because
document
eBay
sequel
API
provides
us
that
functionality.
So
we
run
a
sequel
query
with
a
ver
predicate.
So
here
the
way
predicate
we
are
using
to
specify
the
discriminator.
Since
we
are
only
querying
for
blocks,
we
don't
need
to
get
data
for
post
or
any
other
ng
type
store
in
the
same
collection.
Therefore,
we
introduced
a
discriminator
and,
as
you
can
see
in
the
result,
we
have
the
pre
post
stored
in
the
server
next
we
want.
B
We
would
want
to
load
the
post
for
area
dotnet
blog.
So
first
we
will
query
for
area
dotnet
blog.
We
will
create
entry
for
that
and
use
collection
API
to
load
the
navigation.
So
if
we
go
further
then
so
first
query
we
run
is
to
load
the
area
dotnet
block
from
the
server.
So
here,
in
the
predicate
we
also
specify
C
name
is
ad
or
dotnet.
So
in
currently
implementation
we
have
quite
a
lot
of
unary
and
binary
operator
getting
translated.
B
So
implementation
is
s,
at
least
for
the
filtering
part
or
where
predicate
we
have
quite
a
few
stuff,
which
would
get
server
evaluated
and
would
avoid
fetching
unnecessary
data
from
the
server.
We
are
also
looking
into
improving
and
mapping
the
server-side
functions
from
some
of
the
link
operations
so
that
more
and
most
of
gates
are
very
valuated.
This
is
what
we
have
like
biggest
improvement.
We
have
to
make
in
terms
of
like
query
towards
like
cosmos,
DB.
B
Next
query,
we
run
after
fetching
the
area.
Dotnet
blog
is
to
load
post
of
it.
So
this
is
the
second
sequel
we
generated,
which
is
basically
using
discriminator
on
the
post
and
passing
blog
ideas,
a
parameter
and
the
results
are
like
yeah.
We
have
to
block
for
a
do,
dotnet
block.
We
have
to
post
for
a
dear
or
net
block.
B
Now
we
got
we
save
data
week
where
data.
Now
we
let's
modify
the
data
so
for
the
first
post,
which
says
welcome
to
this
log,
which
is,
let's
just
remove
content
for
it,
because
it
was
just
a
test
block
so
going
further.
Basically,
we
are
going
to
change
the
content
to
content,
remove
and
call
Save
Changes
async.
So
if
we
go
back
to
the
server,
so
this
was
our
first
post
post
ID
one
and
block
ID
one
and
the
content
is
now
content
removed.
B
So,
as
we
can
see
in
our
demo,
so
basically
we
have
got
all
basic
functionality
implemented
in
cosmos
to
be
for
users
to
try
it
out.
We
have
database
creation,
insert
update,
delete,
implemented
a
simple
query:
API
one
thing
probably
people
have
noticed
in
this
demo
is
like
so
ensure
created
and
deleted
or
API
is
like
Save
Changes.
We
are
calling
async
version
of
those,
so
at
present
we
are
using
SDK
coming
from
azure
cosmos
DB,
which
provides
for
DM,
l
and
d.
B
Dl
provides
only
async
api,
so
in
our
initial
implementation
we
have
implemented
it
with
async.
Only
we
plan
to
add
sync.
Api
is
also
with
using
rest
api
n
stuff,
but
it
is
not
yet
in
preview
same
way.
On
the
other
side,
the
query
API
is
at
present
only
sync
based.
We
have
introduced
casing
query
pipeline
also,
so
all
the
queries
being
run
like
you
can
also
run
them
asynchronously,
so
that
is
kind
of
like
one
of
the
limitation
right
now.
B
A
Another
limitation
that
I
remember
and
we
have
in
preview
2-
is
that
inheritance
doesn't
work
very
well
inquiries.
If
you
issue
a
query
for
a
base
type,
then
you
may
not
get
the
drive
type
instances
just
a
bug
in
our
required
implementation.
There
is
that
one
thing
that
we
really
want
to
do,
which
is
the
thing
that
we
talked
about
with
ownership,
that
we
want
to
embed
the
own
entities
in
the
same
JSON
payload
that
we
had
implemented
yet,
and
there
are
like
more
quality
translations
that
we
want
to
do.
Yeah.
B
There
is
so
in
terms
of
cosmos
DB,
since
it
is
a
non
relational
database.
There
are
no
foreign
key
constraints,
so
there
are,
there
is
no
support
for
join,
especially
certain
operations
are
in
cosmos.
Db
are
quite
costly
because
it's
globally
distributed
database,
so
you
may
not
have
all
the
data
a
single
cluster
because
of
that
quite
a
few
things
which
we
realize
could
be
differently
translated.
So
in
the
demo
we
used
load
API
to
actually
load
the
post
in
C
instead
of
using
include
so
the
way
include
has
been
implemented
right
now.
B
It
does
query
for
post
using
inner
join
with
the
blog.
The
first
query:
when
we
try
to
do
the
same
thing
with
cosmos.
We
can't
do
that
because
you
know
joints
are
not
supported.
We
have
to
do
that
on
client,
which
is
going
to
cause
a
lot
more
data
fetching
from
the
server
than
what
is
needed
on
certain
things.
We
plan
to
improve
the
querying
and
stuff
in
a
way
that
there
is
some
intrinsic
based
on
the
design
of
cosmos
to
be
a
certain
query.
B
Operator
does
not
work
and
what
is
the
most
optimal
way
to
get
the
data
so
for
the
join
scenario,
it
would
be
better
to
get
based
on
like
key
values
or
getting
just
based
on
like
where
predicate.
So
those
are
some
of
the
things
we
plan
to
improve
on
query.
There
is
also
like
a
lot
of
server-side
functions
which
are
not
map
right
now,
like
top
and
top
order
by
is
not
server
translated,
its
those
are
minor
things
which
it's
been
based
on
like
it
is
just
taking
time
so
not
being
implemented.
B
A
Another
story
that
we
currently
don't
have
any
any
solution
for
it,
but
that
we
want
to
basically
learn
from
from
the
feedback
that
we
get
on
on
the
provider
is
what
happens
when
you
evolve
the
model
of
the
application?
Let's
say
that
you
are
using
cosmos
DVD
to
serve
data
for
a
mobile
application,
and
then
your
schema
changes
or
well
cosmos
TV
doesn't
have
a
schema,
but
but
you're
the
the
object
model
that
you
are
using
in
your
application
changes
on
the
server
and
then
you
need.
A
You
still
need
to
support
all
the
clients
and
you
need
to
support
new
clients
that
are
going
to
store
new
data
that
they
all
the
clients
turn
support.
So
one
thing
that
we
have
done
to
support
that
already
is
that
when
we
fetch
an
object,
sorry
a
document
from
the
database,
we
keep
a
copy
of
the
whole
document.
We
don't
just
keep
a
copy
of
the
values
of
the
properties
that
are
mapped
to
the
AF
model.
A
We
keep
the
whole
document,
so
nothing
is
lost
when
we
do
a
round
trip,
but
but
the
scenario
in
which
we
need
to
basically
migrate.
The
existing
data
and
the
data
is
to
a
new
schema,
or
things
like
that
is
something
that
we
just
need
to
learn
what
what
the
highest
priorities
are
for
for
our
customers
that
are
using
cosmos.
We
and
we
are
going
to
learn
that
only
through
iterating
over
it
and
talking
to
customers
and
getting
the
feedback.
So
welcome
to
talk
about
that
with
us.
A
So
let's
talk
about
what
we
are
working
on,
so
we
we
are
planning
to
ship
EF
core
2.2
by
the
end
of
this
year.
It's
going
to
contain,
besides
all
the
all
the
features
that
we
talked
about
today.
It's
also
going
to
contain
another
small
feature
that
is
about
having
the
ability
to
reverse
engineer
a
database
view
using
the
feature
that
is
called
query
types.
That
is
something
that
we
introduced
in
UF
core
2.1.
A
That
is
basically
like
an
entity
object,
but
without
a
key
and
is
read-only,
so
this
is
like
ideally
suited
for
for
mapping
to
be
using
databases,
besides
that,
if
we
move
to
the
future-
and
we
talk
about
things-
are
a
little
bit
more
uncertain
in
next
year-
we
are
going
to
ship
EF
core
3.0,
and
we
don't.
We
don't
know
exactly
what
the
feature
set
is
going
to
be.
We
have
been
discussing
more
than
once
different
set
of
features
for
for
EF
color
3.0.
A
Well,
we
know
that
we
would
like
to
include
in
the
releases
in
this
light.
Basically,
with
the
main
thing
that
Smith
is
actually
working
on
is
an
overhaul
of
our
link
under
mentation.
That
is
going
to
make
it
a
more
robust
and
much
better,
and
also
we
have
features
like
the
ability
to
to
map
to
new
constructs
in
c-sharp
eight,
so
c-sharp
eight
is
going
to
explain
into
our
support
for
a
standard
interface
that
represents
a
synchronous
collections.
So
if
you
want
to
string
data
like
a
query,
Chris
query
results,
for
instance,
but
a
synchronously.
A
Currently
we
are
using
a
kind
of
an
more
ad-hoc
version
of
it.
This
interface
is
in
control
that
is
defined
in
Microsoft,
interactive
extensions,
but
now
there's
going
to
be
a
standard
version
of
this
interface
and
it's
going
to
be
included
in
the
language
and
the
language
is
planning
to
do
some
work
to
enable
interesting
features
like
for
each
or
iterators
using
this
interface.
So
we
want
to
converge
to
use
the
same
interfaces.
A
Another
feature
that
c-sharp
eight
is
adding
is
nullable
reference
types
or
actually
what
this
means
is
non
allowable
reference
types.
They
say
the
new
thing
that
we
can
take
advantage
of,
because,
knowing
that,
let's
say
a
string,
property
is
not
going
to
be
nullable,
we
can
make
that
known
on
the
database
as
well
and
at
the
same
time,
when
we
generate
a
sequel,
we
know
that
it's
not
going
to
be
inaudible,
so
we
can
simplify
the
sequence
that
we
generate.
There
are
other
features
like
property
bug
entities
that
we
would
like
to
include
this.
A
This
is
about
being
able
to
map
to
an
object.
That
is
not
the
different
CLR
type
from
the
earth.
It's
not
a
polka,
but
it's
just
a
dictionary
of
string
to
object,
and
this
is
very
useful
for
two
reasons.
One
is
when
we
have,
for
instance,
this
request
to
implement
many-to-many
relationships
with
without
an
entity
in
the
middle
and
that
entity
could
be
hidden,
basically
could
be
just
a
property
bug
that
we
don't
expose,
and
you
can
have
your
navigation
properties
going
directly
from
one
entity
to
the
next
skipping
one
level.
A
Another
feature
that
we
have
here
is,
for
instance,
aggregate
behaviors
are
eight
behaviors.
This
is
also
based
on
this
idea
of
document
databases
and
supporting
cosmos
TV
and
how
we
can
have
like
a
uniform
way
to
represent
certain
constructs
across
different
providers.
So
when,
when
we
talk
about
document
databases,
we
often
relate
that
to
to
aggregate
oriented
databases.
That
is
a
concept
that
Martin
Fowler
talks
about
a
lot
in
one
of
his
wiki
documents.
A
The
idea
is
that,
well,
the
document
is
just
an
aggregate
of
data,
and
if
it
is
an
aggregate
of
data
and
the
ORM
reasons
about
that
aggregate
of
data,
that
aggregate
of
data
can
be
mapped
to
a
relational
database
as
well.
It
doesn't
need
to
be
just
a
document
database,
so
we
are,
we
are
thinking
about
out
of
making
more
automatic
behaviors
around
aggregate
like
cascade
deletes
can
depend
on
on
ownership,
and
they
can
be
automatic.
Things
like
concurrency
control
can
also
be
automatic
in
that
way.
A
The
next
thing
that
we
have
in
this
slide
is
talking
about
a
entity
framework
six-point-three,
a
working
on
dotnet
core
3.0.
This
is
something
that
we
talked
about.
We
started
talking
about
in
May
when
we
did
the
first
announcement
about
what
the
net
called
3.0
was
going
to
be
about,
and
if
you
want
to
go
to
the
next
slide,
so
we
have
a.
We
have
a
number
of
reasons.
A
We
are
doing
this,
so
the
the
main
reason
we're
doing
this
is
basically
because
we
want
people
to
be
able
to
move
from
dotnet
framework
to
dotnet
core
3.0
very
easily
it
on
the
core.
3.0
is
going
to
support
a
number
of
desktop
desktop
a
center
technologies
like
WPF
and
WinForms,
and
we
find
that
many
existing
applications
are
using
EF.
You
have
six
in
particular,
or
previous
versions
of
EF
to
do
date.
Access
and
we
want
to
enable
basically
those
applications
to
move
to
dot
and
core
3.0
very
easily
and
very
cheaply.
A
Although
we
are
not
actually
changing
the
direction,
we
are
still
going
to
recommend
to
use
a
EF
core
for
all
your
new
applications
and
anytime
you,
you
can
afford
porting
to
EF
quality,
point
zero.
That
would
be
recommended
but
path
forward,
and
we
are
not
adding
new
features
to
year
six.
We
are
not
thinking
about
investing
on
on
new
features.
We
can
look
at
pain
points
and
we
can
try
to
solve
pain
points,
and
we,
because
here
six
is
also
an
open
source
pilot.
A
B
A
Made
it
super
hard
for
us
to
to
add
them
so
another.
Another
thing
here
is
that
EF
core
sorry
EF,
6
c
6.3
on.net
core
the
plan
study
is
going
to
be
cross-platform.
There
is
no
reason
to
limit
it
to
just
work
on
Windows.
You
should
work
on
Mac
OS
and
on
Linux,
and
also
a
likely
we
are
not
going
to
have
spatial
support
on
on
when
you
are
running
outside
of
the
net
framework,
because
the
types
that
sequel
server
uses
for
for
spatial
support
directly
that
EF
6
depends
on
only
work
on
dotnet
framework.
A
Currently
and
if
you
have,
if
you
are
working
with
an
existing
provider
like
Oracle
for
instance,
and
you
want
to
a
popular
application
to
dotnet
called
3.0,
then
you
are
going
to
need
Oracle,
basically
to
ship
a
new
version
of
the
provider
that
was
compiled
to
work
on
dotted
core
as
well,
so
well,
that's
all
for
in
taifeng
or
6.30
and
on
the
core.
So
our
final
message,
our
the
most,
are
available
in
this
aka
MS.
A
You
have
core
demos,
link
again,
I,
don't
know.
If
I
set
this
enough,
we
really
need
your
feedback
to
make
sure
that
we
finish
these
features
with
high
quality
and
with
all
the
iterative
process
that
is
needed
to
to
develop
software.
The
main
names
of
the
package
I
put
them
there,
so
that
you
can,
you
can
download
them
very
quickly
and
finally,
we
want
to
thank
you.
We
are
having
a
great
time
developing
software
as
an
open-source
project
with
with
this
developer
community
and
from
the
whole
anti-fungal
team.
A
We
want
to
thank
you
for
all
the
feedback
and
all
the
great
interactions
that
we
are
having.
So
we
are
ready
for
questions
so
the
first
question
I'm
seeing
here
it
says
in
all
EF,
you
made
a
conscious
decision
to
make
a
single
enumeration
for
every
query.
That's
basically
it
says
more
things,
but
EF
core
doesn't
do
that.
That's
a
main
question,
and
this
is
a
very
important
question.
A
This
is
an
interesting
conversation
to
have
so
the
main
one
of
the
the
decisions
we
made
very
early
very
early
when
we
were
designing
EF
College
that
it
wasn't
going
to
be
only
for
relational
databases.
One
thing
that
is
sometimes
different
between
different
kinds
of
databases
is
the
richness
of
the
query
language
that
you
can
use
to
talk
to
the
database
and
the
capabilities
that
it
has.
A
So
we
wanted
to
implement,
link,
ask
the
query
experience,
but
then
we
had
to
translate
that
link
to
to
some
language
that
could
operate
and
to
perform
those
things
efficiently
on
the
server.
Now,
if
you
are
working
with
a
sequel
database,
there
are
a
number
of
things
that
you
can
write
in
link
that
they
are
going
to
translate
to
sequel,
but
there
are
other
things
that
you
can
do
in
link
that
are
not
going
to
be
translate
translatable
to
sequel.
A
Actually
we
got
a
lot
of
feedback
from
customers
using
previous
versions
of
EF.
That
said,
okay,
I,
don't
want
a
EF
to
throw
whenever
there
is
a
query
or
something
in
the
quarry
that
cannot
be
translated
to
to
sequel
they
I
wanted
to
just
resolve
it.
I
I
know
that
it
can
be
a
little
bit
more
expensive
to
resolve
it
in
that
way,
but
if
it
needs
to
issue
more
than
one
query,
I
want
it
to
happen.
A
So
it's
basically
a
user
option
to
be
able
to
do
this
and
what
we
found
is
well
basically
what
we
decided
that
by
default,
EF
Corps
was
going
to
have
this
option
enabled
by
default.
It's
like
if
I
need
to
resolve
a
query
and
it's
going
to
cause
more
than
one
round-trip
to
the
database
is
going
to
do
it
and
it's
going
to
issue
a
warning.
Now
we
have
a
warning
system
that
you
can
use.
A
You
can
configure
to
actually
make
it
throw
in
that
case,
and
we
are
thinking
about
making
it
even
more
easy,
like
you
can
have
a
method
on
the
on
the
query
that
you
can
use
to
say:
okay,
this
this
query
executed,
but
if
it
is
going
to
cause
multiple
round
trips
or
is
going
to
cause
a
lot
of
client
evaluation
and
just
throw
because
I
don't
want
that
to
happen.
So
you
have
anything
to
add
or
to.
B
Add
more
to
that
especially
specific
link
that
questions
say
it
about
n
+1
evaluation,
so
yeah.
It
is
true
that
EF
sake
stayed
only
single
query,
so
there
were
not
more
than
one
query
and
in
certain
cases,
EF
core
is
going
to
do
one
query
for
each
record.
So
that
is
something
which
you
it
happening
right
now,
because
we
don't
plan
to
convert
it
to
how
ef6
work.
The
main
reason
we
moved
to
multiple
query
mode
is
ef6
because
of
it
would
only
single
query
certain
data,
which
is
coming
from
first
query
in
EF
code.
B
It
would
get
duplicated
way
too
many
times,
which
is
unnecessary.
Therefore,
we
move
to
like
split
query
mode
where
we
are
going
to
run
multiple
queries.
At
the
same
time,
we
are
also
looking
into
combining
some
of
the
n
plus
one.
So
instead
of
doing
an
queries,
it
would
do
two
or
three
queries
based
on
how
the
data
is.
We
all
serve
some
certain
tracking
issue
around
where
none
of
those
would
work.
We
would
still
combine
based
on
the
key
value
set.
B
A
B
Certain
example
of
that
would
be
like
group
buy
and
first
oil
default,
which
is
there,
is
no
direct
support
for
that
in
sequel
and
like
there
are
various
way
to
like
write
that
worried
but
yeah.
That
is
something
which
is
a
complex
in
or
if
you
haven't
gotten
around
it,
but
we
plan
to
improve
all
those
kind
of
things
to
avoid
n
plus
1
round
trips.
Yeah.
A
One
one
one
scenario:
we
are
focusing
on
this
question
a
lot
but
I
think
it's
an
important
question.
One
scenario
in
which
is
clear
that,
for
instance,
having
this
model
is
a
benefit
is
when
we
implement
cosmos
TV.
There
are
certain
things
that
you
can
do
in
relational
that
you
cannot
do
like
joins
across
different
collections
or
across
different
entities.
Basically,
so
the
only
way
we
can
implement
that
in
in
EF
core
is
actually
by
doing
some
of
the
valuation
of
that
joining
memory
and.
B
A
Ok,
so,
let's
move
to
the
next
question.
The
next
question
is:
how
is
the
Oracle
connector
coming?
That's
another
good
question
so
that
the
answer
to
that
has
two
layers
and
several
options
in
each
layer.
I
guess
so
there
are.
There
are
providers
that
are
commercial
that
have
been
already
available
for
Oracle
for
EF
core
and
for
a
GeoNet
window
net
core.
Now
the
Oracle
team.
As
far
as
I
know,
they
release
beta
3
of
their
ad
or
net
provider.
A
A
B
Next
question
we
have
is:
can
we
connect
to
MongoDB
using
the
same
cosmos,
TB
API,
so
cosmos
TB
has?
It
is
a
single
database,
but
it
has
different
access.
Ap
is
like
sequel,
API
than
cosmos,
then
Cassandra,
API,
MongoDB,
API,
table
storage,
so
current
implementation
of
sequel
API,
it
actually
targets
sequel.
Only
so,
even
though
cosmos
TB
is
a
single
database,
each
API
has
a
different
set
of
characteristic,
which
requires
different
way
to
access
the
data
or
generate
certain
queries.
B
So
our
current
plan
is
not
to
have
a
provider
which
would
target
all
the
different
API
of
Cosmos
TB.
We
are
making
it
for
sequel
API
right
now,
specifically,
but
we
believe
that
this
work
will
actually
provide
a
certain
non-relational
layer,
abstraction
for
for
people
who
would
want
to
write
a
provider
which
would
target
different
API
is
of
Cosmos
TB
or
even
it
could
target
other
non-relational
database
out
there,
which
are
not
cosmos,
TB
yeah,.
A
Especially
like
MongoDB
and
the
cosmos,
TV
sequel
API
have
in
common
that
they
are
storing
documents
as
JSON.
So
a
lot
of
the
work
that
we
are
doing
in
that
area
is
something
that
can
be
leveraged,
probably
in
a
MongoDB
provider,
but
but
for
instance,
the
sequel
generation
doesn't
make
any
sense.
So
there
is
by
the
way,
a
MongoDB
provider
that
somebody
in
the
community
is
working
on.
A
We
have
had
only
like
initial
conversations
with
people
that
are
working
on
machine
learning
on
the
team
to
see
if
there
is
any
opportunity,
because,
mostly
because
we
have
customers
that
are
asking
the
same
question,
but
we
haven't
learned
much
about
it.
Yet,
let's
keep
what
about
skip
level?
Navigation,
so
that's
one
of
the
components
that
that
we
have
for
the
plan
for
many-to-many.
That's
something
that
we
would
like
to
do
next
year,
but
we
don't
know
exactly
in
what
release
it's
going
to
fit.
A
A
Many
too
many
support
like
was
in
year.
Six.
Yes,
just
answering
the
same
question
again,
we
would
like
to
have
that
next
year,
but
we
don't
know
yet
if
it
is
going
to
fit
and
exactly
in
which
release
is
going
to
fit
any
plans
to
support
single
statement.
Bulk
updates
inserts
deletes
in
the
Cohen
Cohen
instead
of
a
single
query
per
manipulated
row,
that's
something
that
we
have
in
the
backlog
is
not
the
highest
priority.
A
Something
that
is
interesting
is
is
still
not
close,
because
it's
something
that
we
believe
eventually
would
be
very
good
to
work
on,
and
it
would
make
some
scenarios
very
efficient.
The
easiest
of
those
scenarios
is
probably
bulk
deletes
because
you
only
need
like
a
set
of
keys
to
to
generate
the
sequel,
but
it's
not
the
not
the
top
priority,
just
because
we
have
so
many
other
things
that
we
need
to
work
on.