►
From YouTube: Magento Architectural Discussions -- May, 22, 2019
Description
- Compiled interceptors
- Immutable DTO
- Fix for locking during cache generation
Meeting minutes - https://github.com/magento/architecture/issues/164
A
A
A
B
B
E
Have
a
small
comment
from
a
community
perspective,
so
let's
say
this
is
plug-in
in
my
opinion,
like
apart
from
performance
reasons
like
a
performance
issue
is
not
as
big
one
here,
but
the
biggest
one
is
actually
debugging.
So
after
applying
this
one,
you
actually
can
directly
see
without
stuck
trace.
C
F
C
B
D
F
E
I
was
actually
proposing
on
this
poor
request.
I
was
proposing
to
create
file
Watchers
that
watches
the
file
being
changed
on
developer
computer
and
clean
the
generated
classes
related
to
this
file
based
on
the
AI
configuration,
but
nothing
about
actually
recompiling.
So
idea
behind.
This
is
actually
just
to
make
sure
that,
when
developer
refreshes
the
browser
window,
the
file
that
is
not
generated
will
be
generated
automatically
by
magenta
for
the
standard
means
without
any
changes
into
the
way
how
its
compiled
or
how
compiled
classes
are
generated.
E
E
But
it
doesn't
mean,
like
yeah
NFS,
actually,
it's
stupid
to
use
NFS
for
your
development,
because
NFS
is
super
slow
with
number
of
files.
Magenta
has
so
what
I've
seen
so
far
in
community
like
there
is
multiple
developers
who
use
different
tools
like
people
use
units
on
file
synchronization
or
this
new
tool
that
is
available
over
there.
I.
E
Don't
remember
me
John
yeah,
but
the
idea
is
right
to
run
it
on
your
development
machine
and
generate
also
classes
also
to
have
this
one
synchronized
through
unison
or
any
other
means,
with
your
show
machine
where
you
run
Magento
itself,
but
in
general,
like
majority
of
the
distance
right
now,
have
possibilities
to
use
inotify
or
queue
pull
solutions
to
pull
up
for
possible
file,
changes
and
yeah.
It
requires,
let's
say
developer
to
install
some
PHP
extensions.
E
A
A
A
B
F
I
I
Screen,
ok
screen
one
okay
now
should
be
working,
so
the
point
is
to
add
one
immutable.
Dt
of
support
in
Magento
and
I've
been
working
on
this
one
for
for
a
while,
and
basically
the
the
idea
is
just
to
work
with
immutable.
Lead
videos
like
this
one,
you
you
can
see
my
screen,
so
basically
parameters
are
injected
through
constructor
and
you
olia
get
parameters.
I
started
working
on
my
class
that
basically
should
replace
the
data
object
helper
that
is
capable
of
dealing
with
this
kind
of
classes.
I
I
So,
let's
imagine
we
have
a
waiver
imagine
to
class
like
one
product
so
and
we
want
to
adding
an
extension
attribute,
and
this
extension
attribute
is
a
one
immutable
DT,
oh,
if
I
try
to
do
this
in
the
correct
magenta
plantation,
basically,
I
have
a
problem
because
everything
is
handled
by
populate
with
array
in
a
recursive
way.
So
even
extension,
artists
are
being
populated.
I
With
this
system,
I
try
to
create
some
kind
of
hybrid
approach,
I
breed
approach
by
creating
what
we
find
our
hydration
strategy,
but
basically
is
the
feature
of
the
DTO
processor
to
be
able
to
inject
both
mutable
and
immutable
objects.
But
the
problem
here
is
that
I
should
replace
every
single
implementation
of
populate
with
array
in
a
magenta
code
and
of
course,
it's
almost
impossible,
because
I
think
I
can
have
a
lot
of
side
effects,
and
this
is
one
problem.
I
I
think
we
should
discuss
about
the
implementation
of
the
mutable
DTO,
because
I
need
to
find
a
way
to
identify.
One
immutable
object
is
in
magenta
to
be
sure
to
use
the
right
approach
populate
with
array
or
create
from
array
or
the
mutable
and
plus
I
also
introduced
that
kind
of
as
a
kind
of
PS
37.
I
If
we
bring
this
approach
to
Magento,
basically
I
think
we
can
blow
up
every
single
server
of
Magento,
because
the
objects
are
quite
wide,
so
I
ended
up
creating
kind
of
I
call
this
DT
or
mutator.
That
basically
is
a
generated
class,
so
I'm
using
cogeneration.
So
let's
say
I
want
to
mutate.
This
object.
That's
nested,
video
I,
just
pulled
test.
Nested,
eto,
mutator
and
I
have
all
the
Gators,
basically
with
equivalent
with
metered,
but
instead
of
having
one
copy
of
the
object.
Every
time,
I
call
weed,
I
call
a
final
mutate.
I
I
Yes,
we
have
been
thinking
to
a
marker
interface,
but
my
concern
about
a
marker
interface
that
actually
I
have
a
branch
with
with
a
marker
interface,
because
I've
been
running
a
couple
of
tests
is
that
we
are
I
mean
it's
a
kind
of
smell,
because
basically
we
cannot
say
that
one
object
implementing
this
interface
is
actually
an
immutable
object.
I
know
we
can
apply,
let's
say
some
static
test,
but
you
know
it's
not
a
code
constrained.
G
I
We
can
this
was
another
idea.
Actually
they've
been
sharing
some
months
ago
with
with
Igor,
actually
was
slightly
different,
but
basically
it
was
an
XML
file,
defining
the
DTO
there's
no
more
and
it
was
auto-generated
that
was
basically
I.
Don't
know
if
you
mean
this
way,
so
you
define
an
XML
defining
the
DTO
yep.
I
I
So
absolutely
it's
an
option.
It's
an
option,
but
of
course
you
have
XML
and
not
yeah
I
mean,
of
course
you
generate
a
class,
but
you
have
an
X
term
and
instead
of
V
I,
don't
know
how
this
is
appreciated
from
mature
to
developers.
So
this
is.
This
is
absolutely
one
idea
and
I've
been
even
working
on
this
approach,
because
I
have
several.
A
Using
this
proposal
see,
we
can
create
the
immutable
data
already
now,
because
this
proposal
is
backwards
compatible
and
the
wrong
with
that
doesn't
actually
introduce
new
API,
probably
except
the
marker
interface
or
like
we
can
proceed
in
the
result.
Marker
interface,
but
then
you
declaration
is
going
to
be
kind
of
new
from
genomic
in
your
API
and
we
can't
relieve
it
before
to
the
for,
but
already
now
we
have
some
acct
to
introduce
mutable
objects.
G
In
my
thingy,
it
really
depends
in
case
we
are
going
to
switch
the
configuration
it's
a
moment.
It
makes
sense
to
combine
positive
approaches
because
in
other
in
other
hand,
we
don't
have
that
differ
in
the
several
approaches.
We
have
to
build
in
beautiful
objects
now
system
and-
and
it
shows
you
that
this
will
be
good
anyway,
it
in
a
new
feature
or
I
believe
it
can
be
approved
as
a
backward
compatible
change,
because
no
any
of
extension
will
be
affected
by
introducing
a
new
configuration
and
the
new
people.
Oh.
C
A
Okay,
so
like
this
cool
idea,
like
we
already
discussed
this
for
you
from
the
very
beginning
with
Ricardo,
but
currently
like
this
was
probably
several
months
ago,
but
now
we
get
we
good,
but
this
year
in
the
scope
of
the
implementation
of
the
install
become
concurrently
like
we
have
a
higher
architecture.
We
have
the
amplitude
sources
and
the
sources,
but
then
actually
any
source,
which
could
be
beautiful.
It
can
represent
like
warehouse
with
mortars,
poor
distribution
center,
actually,
whatever.
A
A
I
So
basically,
this
is.
This
is
not
a
new
way
of
thinking
to
objects,
of
course,
or
it
is
not
a
fight
between
mutable
and
immutable
objects.
I
mean
you
should
use
mutable
when
you
should,
when
you
have
to
use
mutable
and
immutable
when
you
have
to
use
immutable,
but
for
example,
now,
if
you
take
the
request,
interface
object,
it's
just
an
example.
Why
request
interface
object
is
mutable.
I
I
I
G
F
G
One
case
when
you
have
to
put
your
data
object
as
an
argument
for
another
plugins,
which
probably
wants
to
change
its
state.
The
main
problem.
This
builder,
am
pleased
with
this
change
in
state
that
we
always
face
when
we
try
to
do
something
like
this
was
exactly
in
this
case
that
you
may
have
several
extensions
that
may
want
to
change
your
objects
on
fly
during
execution
right.
G
I
F
A
A
I
Yes,
but
if
you,
if
embed
logic
in
the
DTO
itself,
basically
you
need
to
create
a
copy
of
the
object
for
each
single
parameter,
you're
going
to
change.
So
the
idea
of
this
potato
was
to
avoid
these.
So
if
you
need
to
change,
let's
say
like
in
this
example:
I'm
sharing
I
want
to
change
three
parameters:
I,
don't
need
to
have
three
copies:
I,
just
well:
I
have
one
P
when
I
call
mutate.
Oh,
this
is
the
main
difference
and
I
want
to
discuss
about
these.
C
A
E
E
Okay,
do
you
see
my
screen?
Yes,
oh
sorry,
I
need
to
close
this
one
out.
Okay,
so
here's
my
screen
very
interesting
one.
So
the
problem
right
now
is
around
the
way
how,
as
the
cash
is
getting
loaded
in
magenta,
because
in
recent
2.3
release
there
was
introduced
a
way
to
walk
cash
during
writing
to
it.
So
let's
say
when
you
have
a
lot
of
concurrent
users
and
then
someone
triggers
the
clashing
of
the
system
cash.
B
E
E
So
in
cases
where,
let's
say
you
have
a
cat
be
not
generated,
yet
it
puts
your
Magento
request
with
concurrent
requests.
At
the
same
time,
let's
say
in
developer
mode,
where
you
have
also
to
get
PHP
involved
for
static
content
and
everything
else.
It
puts
all
those
processes
to
sleep
until
the
cache
data
gets
gonna
raid,
so
developers
when
they
developed
something.
They
feel
a
lot
of
lag
in.
E
Exiting
the
store,
however,
yes,
there
is
some
merits
in
actually
using
logs,
because
I
was
working
a
lot
with
merchants
who
have
had
this
problem
before
in
magenta
one
a
lot
especially,
and
we
had
to
patch
the
mage
core
config
model
that
in
a
racist
cache.
In
order
to
make
sure
that,
during
the
write
operation
we
acquire
a
lock
and
when
we
acquire
a
lock,
the
other
processes
are
not
gonna
overwrite.
E
The
data
after
our
lock
is
happening
so
before
like
there
was
implementation
that
was
locking
the
configuration,
but
it
was
not
checking
if
other
process
just
was
working
before
you
actually
tried
to
check
if
it
was
locked
before
so
it's
a
little
bit
complicated
the
implementations.
It
was
happening
in
magenta,
one
in
magenta.
It
was,
it
is
solved
in
such
a
way
what
I
was
doing
for
magenta
one
customers.
E
K
K
K
K
K
K
K
So
now
we
are
discussing
about
cell
discussion
is
about
removing
this
second
level
optimization
because
it
causes
more
problems
than
it
solves,
so
fall
back
to
just
having
a
lock
on
single
process
and
not
preventing
all
other
processes
from
reading.
So
every
process
will
still
read
the
configuration
and
match
it
and
process
it,
but
will
not
write
to
care.
So
we
will
still
load
our
CPU
and
our
phone
system,
but
that's
not
a
big
deal,
it's
much
better
than
introducing
locks
that
will
cause
problems
in
some
scenarios
right
overall
description
of
the
problem.
E
So
it's
basically
a
good
description.
I
couldn't
put
it
better
than
you,
so
in
general,
this
is
apart
from
Z.
There
is
terrific
theoretical
possibility
that
under
high
load,
when,
let's
say
the
car
generation
would
take
a
lot
of
time
that
all
the
backend
requests
that
run
concurrently
will
actually
wait
for
this
one
to
be
completed
by
depleting
the
FBM
process
pool
on
a
server
so
ballad.
This
is
I
was
unable
so
far
to
replicate
with
load
test,
because
I
don't
have.
K
I
think
it
makes
sense
to
remove
this
lock,
because
we
know
that
least
one
scenario,
but
it
practically
causes
problems.
We
could
think
about
solution
to
solving
the
scenario
where
caches
are
disabled
by
Y.
Do
that?
If
the
benefit
of
the
solution
is
not
such
a
big
now
so
I
think
we
have.
Everybody
agrees
that
it
should
be
removed
right.
E
K
E
E
In
some
case,
the
cache
server
like
radius,
let's
say,
goes
down
during
the
write
operation.
It
means
yeah
and
until
you
know
the
main
process
fails.
You
know
and
then
locks
the
cache
we
are
here.
It's
finally
is
working,
but
let's
say
if
this
situation
happens
and
somewhere
the
cache
server
goes
down.
It
means
that
then
the
same
problem
as
in
developer
mode
will
happen
on
production
as
well,
because,
let's
say.
E
Let
me
just
apply
some
of
the
changes
I
was
doing
so
here
is
the
standard
implementation.
So
this
one
I,
don't
I,
didn't
touch
in
my
pool
request,
so
I
created
another
method
under
the
lock
cache
guard
class
called
non-working,
lock.
Claude
said
that's
the
things
that
you
just
described,
that
we
just
checked
for
the
lock
and
then,
if
the
process
was
locked,
we
only
in
this
case
we
save
the
data.
E
If
the
process
is
not
worked
and
we
can
acquire
the
lock
otherwise,
we
just
return
the
data
that
was
collected
back
to
the
user,
so
the
process
works
well
without
you
know
generating
it
again.
Apart
from
that,
after
some
discussions
with
Andrea
I
was
thinking.
How
can
we
actually
improve
the
generation
process
and
I
created?
You
call
a
book
here
called
stale
beta
loader,
so
let's
say
we
can
retrieve
the
data
from
cache.
E
We
just
returned
it
back
if
it's
locked
and
we
have
a
stale
data
loader,
then
we
retrieve
data
with
this
stale
data
loader
back
to
the
user
other
ways.
Otherwise
we
will
get
irate
the
data
through
the
data
collector
itself.
So
the
basic
idea
here
is
that
when
we
save
the
original
cache,
we
create
as
well
another
entries
that
will
contain
a
stale
cache
that
we
can
use
to
retrieve
data
during
generation.
For
all
the
other
processes,
there
was
valid
concern
from
Andrea
concerning
the
page,
cache
and
other
parts
of
the
systems.
It
can
be.
E
How
do
I
call
compromised
by
the
inconsistent
data?
So
let's
say
you
can
store
the
page
cache
entry
in
warnings
that
would
still
be
served
for
a
long
time
with
this
stale,
cached
data
and
produced
and,
of
course,
the
wrong
date
on
the
front
end.
However,
this
one
can
be
solved
by
just
disabling
the
page
gate
for
the
pages
that
received
stale
configuration
cache,
so
it
just
can
be
resolved
through
the
plug-in,
and
another
issue
was
let's
say
when
we
have
other
caches
apart
from
page
cache
like
what's
a
block
ECML
cache
or
collection
cache.
E
That
also
will
rely
on
configuration.
Well,
yes,
but
I
already
found
out
that
Magento
doesn't
solve
this
problem
even
right
now,
because
if
I
change
the
configuration
value
and
flush,
this
configuration
cash
at
the
moment
and
I
have
to
say
in
other
cache.
That
depends
on
this
configuration
value
that
other
cache
is
not
clutched
in
Magento,
so
I
was
able
to
replicate
it
by
enabling
price
block,
HTML
cache,
changing,
let's
say
the
currency
code
and
removing
the
currency
code
from
this
block.
E
Html
cache
key
and
the
problem
was
reproduced
very
easily
like
on
John
2000,
clockwork
HTML
key
one
with
flash
configuration
cache.
So
it's
very
simple
one
to
understand,
I,
think
and
then
we
have
already
a
solution
for
such
cases.
Let's
say
if
your
data
depends
on
other
parameters
like
what's
a
currency
code
or
the
tax
calculation
functionality
like
tax
configuring,
tax
calculation,
gradation
or
anything
else
from
outside
of
your
internal
data
that
has
been
returned
to
be
cached.
You
usually
just
add
this
data
as
a
part
of
the
cache
key.
E
So
when
that
other
data
is
changing,
you
would
create,
let's
say,
a
new
cache
key
entry,
and
then
you
will
never
get
stale
cached
data
for
your
functionality,
so
this
is
actually
happens
with
price,
a
block,
HTML,
cache
and
I.
Don't
think
like.
We
will
have
a
big
problem
if
we
just
serve
some
tail
country
cash,
while
other
processes,
while
the
main
process
writes
data
to
cash,
we
just
returned
back
the
other
ones.
So
it's
going
to
be
like.
E
E
E
It's
out
so
this
stale
cash
gets
saved
during
a
single
locked
process.
So
idea
is
that
we
only
lost
one
time
and
we
only
logged
you
in
right
operation.
So
we
don't
lock
it
during
the
read
and
we
don't
wait
for
the
walk
on
the
read
operation.
So
we
have
only
one
writer
is
responsible
for
entry
into
the.