►
From YouTube: Magento MSI Open Demo. March 22, 2019
Description
Agenda:
- In-Store Pickup general updates and results of Grooming meeting by @Aleksandr
- The refactoring of Legacy to New Inventory synchronization and proper modularity. by @TheRick
- The idea of performance improvement based on MySQL Triggers + comparison of existing 2.3.0 + MSI against Trigger version by @wexo-richard
- Decimal Qty comparison fix by @larsroettig
- General updates and outputs of In-Store pickup grooming by @ishakhsuvarov
- QA status by @Tom Erskine
A
A
Any
changes
happened
to
to
inventory
anymore
and
the
one
with
that
recorded
made
quite
a
deep
refactoring
and
improve
the
modularity
of
what
we
have
and
also
Richard
will
will
make
us
break
interesting
values
on
on
a
performance
comparison,
and
he
also
brought
pretty
interesting
idea
and
proposal
how
we
can
improve
that
MSI
performance
until
the
time
we
will
will
have
the
support
of
the
bundled
product.
So
quite
a
lot
of
interesting
updates
and,
let's
start
from
Alex
krafchick
who's,
currently
gern.
B
A
C
Hello
guys
so
I
am
dates
even
will
not
be
long
to
share
with
screen
yes.
So
currently
we
have
three
pool
requests
from
last
week.
First,
pull
request,
is
it's
related
to
the
idea
of
marking
for
order
school
which
were
placed
to
is
in
store,
pickup
method?
So
yesterday
we
have
a
grooming
meeting,
and
so
we
decided
which
naming
we
will
use
for
or
inventory
in
context
of
store
pickup.
It
will
be
pickup
location,
so
I
factor
in
this
pull
request
and
change
it
and
have
changed
the
name
to
the
pickup
location.
C
C
C
Yeah
and
the
last
one
is
related
about
attribute
joint
order
collection.
Actually
it's
about
extension
attribute.
So
as
we
decided
that
in
2.32
we
will
be
available,
bug
fix
for
this
problem,
but
actually
we
are
going
to
use
these
things
in
store
pickup.
So
we
need
to
provide
our
our
fix
in
scope
of
the
store
pickup
to
use
the
dates
feature.
I
have
created
poor
request
based
on
the
poor
request,
the
magenta
core.
C
It's
what
he,
this
polar
test
replies
order,
magenta
order,
repository
I
provided
interface
and
place
it
in
inventory
sales
I
already
we
have
review
from
yoga
and
we
decided
that
place
it
in
magenta
inventory
sales.
It's
not
a
good
idea,
because
replacing
of
all
the
repository
require
a
dependency
on
the
tux
model
and
we
don't
want
to
have
dependency
on
that
talks
model
in
inventory
sales
and
currently.
A
For
order
repositories,
it's
much
better
and
the
safer
just
to
introduce
own
implementation
and
provide
that
implementation.
Vad
I,
as
you
did
so
we
we
can
know
for
sure
that
we
are
not
affecting
anybody
else
and
also
along
with
that.
We
we're
getting
some
performance
boost,
though,
that
we
we
have
just.
We
substituted
the
implementation,
but
we
are
not
around
organization
which
are
pretty
costly
from
the
from
the
performance
point
of
view.
A
I
saw
some
so,
but
we
we
expect
this
will
release
in
store
pickup,
along
with
new
release
of
MSI,
which
is
quite
independent
out
of
magenta.
Earlier.
That's
why
we
will
provide
the
same
fix
in
this
cup
of
MSI
and
in
the
scope
of
MSI
we
wouldn't
be,
as
we
are
not
eligible
to
introduce
any
changes
to
quark
code.
So
we
are
not
eligible
to
introduce
changes
to
order
repository
so
that
what
we
will
do,
we
will
introduce
our
own
version
of
order
repository
and
just
override
it.
D
A
A
Okay,
so
let's
proceed
then
to
performance
updates
and
not
not
just
performance
but
also
structural
update,
because
required
the
heading
may
make
a
great
job
or
because
you
know
like,
like
everything
in
MSI,
started
from
the
small
task
and
end
up
with
a
big
refactoring,
some
modularity
changes,
introducing
CQRS
and
the
even
sourcing
patterns.
So
you
never
know
whether
the
ticket
is
really
small.
A
D
I
think
you're
right
because
we
started
with
a
very
simple
task
and
we
ended
up.
I
ended
up
changing
the
house
pretty,
so
it
was
crazy.
So
the
main
idea,
can
you
see
my
screen?
Yeah?
Okay,
so
the
main
idea
was
to
improve
the
performance
while
saving
one
product,
because,
as
you
know,
and
as
Seager
was
saying
before
every
time
you
save
something
using
MSI.
D
Of
course
we
were
depending
from
the
synchronous
operations,
so
we
decided
to
create
a
new
module
that
we
named
inventory
legacy
synchronization.
So
basically
we
moved
all
the
synchronization
logic
that
was
mainly
located
and
inventory
catalog
before
raw
plugins.
We
decided
to
move
in
this
new
module
and,
of
course,
through
plugin
ization,
and
basically
this
module
can
both
handle
these
synchronously
and
asynchronously,
and
you
can
decide
it
rule,
of
course,
when
admin
settings
so
we
had
even
to
introduce
another
module.
That
is
meta
legacy.
A
It
was
not
literally
just
a
plugins
because
it
was
service
is
used
by
plugins
as
well.
But
this
storage
is
used
solely
by
plugins,
so
we
can.
We
can
consider
them
as
a
one
mechanism
so
that
we
discarded
with
the
Ricarda
so
for
the
sake
of
better
modularity
and
they
take
and
like
having
a
really
low
chances
that
these
tsarouchas
could
be
reused
or
extended
by
extension
developers,
and
especially
some
of
these
classes.
A
We
were
marked
precisely
like
this:
is
the
private
coordinates
of
a
shouldn't,
be
you
shouldn't
be
either
extended
or
modified
by
third-party
developers.
We
agreed
that
we
can't
afford
this
this
changes
and
we
will
be.
We
will
be
releasing
this
in
this
which,
like
by
the
way,
introduce
one
more
additional
modules
to
MSI.
A
Probably
it's
not
the
freshest
result
Ricardo's
breath,
but
the
one
which
which
were
like
which
existed
like
a
few
days
ago,
but
still
it's
pretty
interesting
from
the
from
the
from
the
measurement
point
of
view
and
what
what
else
we
currently
have
so
reach
out
the
feel
free
to
share
your
screen
and
tell
us
the
story
of
of
MSI
and
four
months.
Yeah.
B
E
B
Cool
okay,
so
basically
we
have
a
stall
with
first
I'll.
Just
tell
you
that
I
am
working
at
the
agent
agency,
so
we
have
a
lot
of
different
customers.
This
specific
customer
has
about
seventeen
seventy
thousand
products,
so
whenever
we
enabled
the
MSI,
we
experienced
a
very
slow
pitch
loads
on
category
pages
also,
we
experienced
the
the
issues
that
are
already
apparent
with
saving
products,
but
yeah
here
is
a
very
beautiful
Excel
spreadsheet,
with
time
to
first
byte
for
category
pages,
so
I
have
made
as
four
different
sections.
B
B
If
we
take
Ricardo's
fix,
I,
think
I
am
pretty
sure.
I
pulled
this
changes
today.
This
afternoon,
so
the
code
itself
should
be
pretty
recent
little
take
about
20
seconds
27
seconds
for
a
page
load.
If
we
combine
Ricardo's
fixes
with
our
fix
with
latest
our
table
instead
of
lady
stark
view,
we
get
down
to
about
10
seconds,
page
load.
So
with
a
little
graph
here,
we
can
clearly
see
that
we
have
an
issue
with
the
view
here,
yeah.
B
So
basically
we
dive
deep
down
into
what
my
skull
was
doing
and
we
observed
that
for
each
product
we
ran
a
query
that
took
about
300
milliseconds,
so
we
have
some
large
categories
and,
of
course,
those
affect
quite
a
bit.
This
is
the
query
we
found
and
this
specific
join
here,
which
I'm
here
is,
is
guilty
of
most
of
the
time
consuming
stuff.
B
B
B
We
have
I
think
you
know
you
proposed
to
change
somewhere
that
we
have
to
test
also
regarding
performance.
So
after
we
have
to
check
that
we'll
have
to
figure
out
if,
if
this
solution
is
the
right
one
for
now
or
if
we
should
go
with
an
another
solution,
we
just
know
that
we
have
to
avoid
joining
the
view,
because
city
affects
performance.
So
much
think
that
was
that
was
the
grasp
of
it.
A
Great
research,
so
yeah,
so
the
main
idea,
like
the
one
thing
that
we
should
mention
and
then
that
we
like
because
I
was
I,
was
pretty
interested
to
see
that
we
have
some
difference
between
current
implementation
on
triggers.
So
what
literally
Richard
proposed
to
introduce
lis?
He
proposed
in
to
use
a
mechanism
which
could
be
considered
as
a
materialized
view
where
we
have
the
real
table,
which
is
updated
with
triggers
and
like
I,
expected
to
see
pretty
much
the
same.
A
A
Just
just
fixing
this
class,
but
if
you'll
still
see
that
the
deferred
like
that,
we
have
like
a
difference
between
the
trigger
based
on
provisions
in
my
sequel
views
of
that
we
will
release
the
trigger
base
approach
and
then,
as
it
might
release
and
until
the
time
that
bundle
product
would
be
supported
because
we
don't
want
affect
the
real
merchants.
We
started
to
migrate
and
magenta
to
the
street
at
all
and
will
be
migrated.
A
You
know
magenta
to
distribute
auto
that
one
until
the
time
when
we'll
have
support
for
the
bundled
product,
so
the
we
will
do
is
the
best
way
for
for
the
merchants
from
the
performance
standpoint,
just
just
pretty
interesting
to
see
the
whole
picture
and
see
like
what
would
the
real
performance
degradation
we
have
and
what
the
the
best
approach
for
us
to
choose
now
as
a
as
a
workaround.
So
if
I'm
not
wrong,
Richard
already
promised
to
to
play
around
with
that
and
to
show
I'll.
F
B
A
Because,
in
your
initial
pull
request
that
you
mentioned
that
you,
you
experienced
some
degradation
on
the
product,
the
operation
is
actually
the
pull
request
which
supposed
to
improve
the
degradation
and
but
to
God.
Together
all
benefits.
You
should
switch
manually
to
the
I
think
erroneous
mode
in
a
configuration.
A
The
as
as
I
mentioned
to
do
research
slightly
drunk
and
that's
probably
the
reason
why
most
of
merchants
are
upgrading
to
that
much
version
of
the
product
which
is
released
afterwards
of
the
big
major
update,
and
this
is
been
pretty
typical
to
MSI
as
well.
That
is
why
you
see
that
we
have
a
bunch
of
performance
updates
in
a
quite
released
after
the
after
the
major
general
will
ability
release
of
MSI
yeah.
A
So-
and
this
is
this
really
helpful-
and
this
is
really
very
great-
to
see
the
feed
bags
on
real
use
cases
on
the
real
web
sites
and
like
the
the
SQ
database
is
also
pretty
good,
so
you
should
have
playing
around
with
70,000
of
sq
on
his
torso
yeah.
So
this
is
pretty
much
pretty
much
a
good
case
for
us
to
consider,
though,
now,
let's
proceed
further
and
the
next
one
gonna
be
gonna,
be
you
again
we
will
share
with
you
update
on.
Will
you
use
your
mic?
A
G
F
For
that
bill,
good
now
so
I'll
try
to
be
brief.
Just
want
to
summarize
yesterday
grooming
session,
because
today
we
have
more
people
I.
Think
due
yesterday
we
had
a
blast
grooming,
the
Messiah
and
decided,
if
you
on
few
important
points
which
would
dictate
the
future
of
the
project
so
just
make
more
fun.
I'll
share
screen
with
sample
request,
but
nothing
special
here.
First
of
all,
one
of
the
decisions
was
to
introduce
the
additional
attributes
to
this
tour,
which
would
be
implemented
as
an
extension
attributes.
F
One
of
them
would
be
responsible
for
the
pores
eligibility
for
this
store
pickup
and
the
other
one
would
dictate
the
source
type,
which
then
consequently
may
be
used
for
this
whole
source
selection
algorithm.
We
already
have
a
pull
request
dated
back
to
February,
which
we
still
haven't
processed
I'm
working
on
it
now
and
basically,
what
it
does.
It
already
introduces
in
like
some
sort
of
this
capability,
but
not
in
a
completely
desired
state,
so
we'll
be
doing
a
review
and
getting
it
merge
as
soon
as
possible.
F
The
second
one
we
have
already
seen
today
this
is
about
the
marking.
All
this
with
store
pickup.
This
is
like
another
decision,
so
implementation
is
going
on
here
and
last
changes
were
done
like
few
hours
ago,
so
you
see
I
still
have
like
review
review
requests.
We
shall
be
working
on
after
this
meeting.
F
F
How
would
we
integrate
that
into
checkout
and
in-store
pickup
flows
so
that
when
to
do
X
and
UI
designers
to
figure
out,
which
would
be
the
best
ways
to
present
it
to
the
end-user
so
right,
hopefully,
I
hope
we
will
get
back
bits,
maybe
on
the
next
meeting
or
in
a
few
weeks
with
some
complete
mock-ups
and
maybe
even
some
some
functional
UI
also
I
think
this
is
pretty
much
it
from
my
hands.
I,
don't
want
to
take
to
take
up
too
much
time
so
now
Lars,
it's
your
turn.
I
guess.
G
Thank
you
so
last
update
from
my
side,
and
you
should
see
my
screen
okay
and
on
the
last
hackathon
I
was
working
on
the
date.
Small
order,
incrementing,
Park
and
yeah
I
am
made
a
fix
for
that.
It's
not
really
a
big
fix,
but
it
takes
some
time
to
find
out
what
happened
if
we
had
decimal
amount
of
quantity
there
and
we
had
some
rounding
problems
and
I
also
add
the
test
case,
therefore
afforded
for
this
back
yeah.
This
was
my
update
from
the
last
hackathon
currently
I'm,
working
on
issue
and
verifying
the
issue.
G
I
already
a
node
acknowledge
the
issue
because
I
can
reproduce
the
issue
and
for
this
issue,
I
have
to
wanna
it
because
takes
two
days
or
two
evening's
to
find
out
what
happened
there.
The
main
problem
is
currently:
if
you
go
in
the
back
end
and
save
a
product,
this
out
of
stock,
like
in
the
advanced
inventory,
manage
stock.
No,
you
must
not
assign
sources
and
is
the
product
also
assigned
to
a
website
death.
This
website
has
no
default
stock
like
or
order
stock.
Then
it
breaks.
G
You
cannot
order
this
item,
you
get
a
exception
to
short
updates
why
it
happens.
First,
the
index
doesn't
check
for
the
items
they
are
missing
in
the
index
table.
If
you
take
a
look
for
this
example,
I
have
stopped
for
currently
I
yesterday
I
played
around,
but
if
you
don't
do
it,
it
completely
missing
there
the
items,
so
this
is
the
first
part.
This
is
why,
because
why
happened?
G
It
happened
because
the
current
implementation
after
index
are
asking
the
the
stock
item
table,
not
the
legacy
stock
item
table,
but
the
stock
item
suicide
table
can
be
empty
where,
if
you
don't
assign
any
source
to
the
product,
just
tables
and
empty
for
the
product.
This
is
the
first
problem,
and
the
second
problem
is
we're
asking
for
is
the
product
assigned
to
stock
only
for
the
linked
table,
but
this
table
is
also
empty.
If
you
don't
assign
a
source
to
a
product,
yeah
too
short,
updates
I
think
it
takes
some
time
to
implement
a
fix.
A
Let's
say
if
you
have
like
several
warehouses
in
in
in
in
Germany
in
Italy
in,
for
example,
I
say
in
Ukraine,
though,
and
all
of
these
three
warehouses
are
combined
and
one
European
stock.
So
to
make
the
product
appear
in
the
European
stock,
you
should
assign
the
product
to
particular
warehouse,
but,
along
with
that,
we
have
products
which
could
be
configured
as
managed
inventory,
Falls
to
manage
stock
falls
and
from
the
merchants
perspective,
if
your
should
have
specified
that
he
he
doesn't
want
to
bother
himself
with
managing
stock.
A
It
doesn't
make
really
business
sense
to
assign
this
product
to
one
of
these
sources,
because
he
doesn't
want
to
bother
like
like
to
us
to
to
manage
stock
at
all.
So
what
it
actually
means
for
us
that
products
like
products
which
manage
stock
zero
can't
get
to
do
any
of
stocks.
You
know.
So
what
do
we
agree
to
is
that
we
have
a
like?
A
Currently
we
have
a
workaround,
so
you
can
assign
some
merchants
you
can
assign
that
product
with
one
of
the
sources
and
the
the
quantity
quantity
for
the
product
would
be
just
zero
and
the
way
we
handle
that
situation.
But
but
probably
this
is
not
the
real
like
business
which
we
want
to
handle,
though
that
main
idea
was
to
how
we
actually
handle
and
how
we,
how
we
determine
whether
product
to
the
pier
on
stock
and
all
so.
A
We
like
preserve
the
tours
a
silent,
but,
along
with
that,
we
choose
like
we
determine
for
all
the
products
which
have
the
inventory
configuration,
manners
or
zero
we
determine
to
on
which
we're
on
which
website
they
are
assigned
to
and
for
this
website
assignment
we're
at
this
product
to
the
particular
stocks.
So
we
introducing
one
more
possibility
how
the
product
can
appear
on
the
stock
level.
So
and
this
case
is
managed,
took
zero
for
for
their
website
assignment.
A
So
it's
a
little
bit
tricky
and
it
can
be
sound
like
tricky,
but
we
stuck
with
that
case
for
for
the
sales
channel
integration,
where
we
have
the
integration
of
Magento
with
Amazon
Marketplace,
so
that
some
of
the
products
are
handled
by
Amazon
would
be
marked
as
like
manage
stock
zero,
and
we
just
like
we
just
want
guys
from
the
sales
channel
track
just
want
to
introduce
any
assignment
that
product
to
any
sells
like
to
any
sources
you
can't
they
have.
So
that's.
A
Why,
like
the
fix,
the
the
fix
which
a
lot
of
country
working
on
would
be
pretty
pretty
picky
useful
for
the
magenta
and
the
Amazon
integration,
so
you're
doing
a
great
job.
Flowers,
so
just
push
the
temp
and
continue
continue
this
ticket,
because
guys
from
the
sales
channel
track,
have
pretty
pretty
tough
terms
to
release,
though
that
the
line
is
really
approaching
so
we're
well,
you
are
the
last
hope,
so
this
is
probably
pretty
much
all
regarding
the
update.
Just
let
me
make
a
quick
glance
on
the
on
our
agenda
weather.
A
We
have
anything
else
to
share
with
you,
though
yeah
the
last
but
not
least,
gonna
be
Tom.
Who
will
share
with
you
the
quality,
Quality
Assurance
update
and
what
would
start
of
the
regression
we
have
on
the
MSI
track
and
the
weather.
We
have
anything
you'd
like
anything
you
cool
to
share
with
you
guys.
Well,
don't
you
finish
sure.
E
E
So
as
Igor
mentioned,
the
current
quality
position
is
that
we
are
in
a
regression
cycle
that
one
100
regression
cycle
ongoing,
nearing
completion,
we're
looking
at
hopefully
within
the
next
week
when
that's
finished
up
we'll
do
sort
of
an
overall
breakdown
of
where
that
was
and
get
a
better
idea
of
what
our
quality
position
is
and
all
of
our
efforts
have
been
focused
around
that
right
now
and
so
we've
not
pushed
on
new
test
creation.
So
there
is
a
backlog
of
new
test
creation
than
it
needs
to
be
done
post
this.
E
So
in
sort
of
suppose
that
would
be
April.
There
will
be
quite
a
lot
of
new
tasks,
credit
or
they
were
planning
for
em
and
I'd
of
the
back
of
what
comes
out
of
ration
as
well
so
looking
at
bugs
over
the
last
week,
then
so
we
had
six
issues
open
at
the
project.
One
closed
of
those
six
issues.
Three
were
confirmed
as
bugs
one
got
closed
out
and
the
currently
open.
Then
we
have
mentioned
on
this
call,
20,
97
and
and
also
2087,
so
just
two
setting
open.
E
We
expect
to
get
resolved
in
terms
then
more
slight,
deep
dive
and
where
we
are,
automated
testing
will
run
through
first
then
briefly,
because
it
hasn't
been
a
great
deal
of
change
as
we
see
with
our
trends
since
we
started
regression,
all
of
the
trending
lines
have
flattened
out
again
in
April.
We
want
to
tick
those
up
again
and
add
some
more
coverage
automate
test
by
severity,
no
change
and
component
no
change,
but
we
will
continue
to
report
on
this.
E
So
when
we
do
add
those
in
April,
we
will
see
this
change
as
we
go
forward.
The
manual
testing
then,
which
covers
this
one
100
regression
cycle,
so
the
manual
testing
is
all
of
the
tests,
including
those
that
are
currently
automated
sore
manual
testing
and
automated
testing.
But
this
regression
cycle
of
602
tests
covers
even
tasks
that
are
automated,
so
we
have
sort
of
a
manual
verification
of
those
are
computer
proctoring,
and
this
is
probably
the
most
important
where
we
are
right
now
we're
up
to
a
total
of
546
tests
of
602
total.
E
E
Several
of
those
are
outside
of
the
MSI
project
and
defects
find
in
Magento
core
which
are
being
handled
as
well
and
we'll
get
those
fixes
back
and
retest
these,
and,
but
essentially
this
is
where
we
stand
with
546,
complete
and
looking
to
hopefully
finish
that
out
and
within
a
week
or
just
slightly
over
and
then
we'll
be
able
to
do
sort
of
a
retrospective
on
this
regression
cycle
voice.
That's
us
for
this
week.
If
anyone
has
any
questions,
they're
asked
now
or
feel
free
to
get
me
on
slide.
A
Cool,
thank
you.
Tom
so
looks
like
it's
pretty
much
all
regarding
regarding
today's
presentation.
If
there
are
any
other,
is
there
any
other
open
question
which
you
would
like
to
discuss?
This
is
the
right
time
to
raise
this
question.
If
no
will
open
either
me
or
you
can
with
here
who
still
here
so
don't
don't
hesitate
to
drop
us
a
message
or
just
a
message
to
them.
Aside
like
channel,
there
are
a
bunch
of
people
who
will
help
you,
or
at
least
try
to
help
you
as
we
usually
do.
So.