►
From YouTube: Magento Architectural Discussion -- October, 30, 2019
Description
* Update to technical guidelines: entity IDs
* Make gender more inclusive
* Adding new configuration path (in system.xml) minor or patch change
Meeting minutes - https://github.com/magento/architecture/issues/335
A
A
A
So
it
goes
from
some
discussions
which
are
going
around
graph
KL
and
at
least
there
and
from
our
technical
vision
in
the
future,
so
client-side
generated
ideas
would
help
to
resolve
some
problems
with,
for
example,
import-export
David
also
allowed
to
have
more
flexible
flows
when
creating
horrible
yeah,
specifically
about
creating
of
entities.
So
that's
what
I
propose
and
for
graph
QL
what
we
say
that
output
types
that
represent
entities
which
should
be
manipulated,
updated
removed,
etc
and
or
can
be
cached
on.
A
The
client
must
have
ID
field,
specific
name,
ID
and
type
of
the
should
be
ideal
yeah.
So
that's
related
to
the
request
from
I
believe
PW,
atrium
or
maybe
from
the
community
to
have
ID
field
for
all
entities
so
that
it
can
be
automatically
cached
by
button
by,
for
example,
a
polo
client
and
yeah.
We
were
discussing
that
it
looks
reasonable.
A
B
A
A
So
we
consider
that
it
would
be
good
to
change
type
as
soon
as
possible,
because
we
have
fewer
clients
that
use
graphic
UL
right
now,
but
from
another
side,
I
agree
that
it
probably
it
is
probably
not
a
good
practice
to
make
breaking
changes
in
patch
release
and
having
like
better
predictability,
is
also
important.
So
I
would
say
that
we
need
to
go
through
each
case
or
we
can
discuss
separately.
What
do
we
do
with
all
this
existing
fields?
A
We
have
items
for
architecture
team,
to
create
tasks
for
that
and
I
think
when
we
will
be
creating
such
tasks.
We
can
go
and
discuss
this
product
team
and
with
release
management
team
on
what
do
we
do
with
each
specific
case
or
in
general,
and
we
will
either
label
them
for
2.4
or
2.3
if
it
will
make
sense.
A
B
This
is
this
question
is
related
to
issue
that
that
was
created
after
the
schema
reviewer
and
by
architecture
team.
It
says
that
this
issue
states
we
need
to
convert
gender
field
to
the
enum
type,
and
here
we
have
one
reasonable
comment
from
woman
about
this,
that
in
case,
if
we
will
make
this
innum,
it
became
like
less
less
inclusive
and
the
best
practice.
B
She
also
attached
link
to
the
article
and
best
practice
is
to
just
make
it
free
form,
entry
and
like
what
what
do
you
think
about
it
in
general,
because
right
now
in
Magento,
we
have
right
now
in
schema.
It
is
integer.
So
if
I'm
not
mistaken
one
for
my
o2
for
female
and
in
case,
if
I
want
to
change
to
freeform
entry,
it
should
be.
It
should
be
changed
not
only
on
crack
yourself,
but
on
global
level.
A
D
I
don't
have
anything
to
share,
but
the
question
is:
should
we
consider
adding,
you
know,
configuration
as
a
minor
change
or
in
Japan
change
by
ad
new
configuration
plan
same
agent
Samson
to
system,
if
some
of
the
reason
why
we
may
want
to
consider
this
as
a
minor
changes
because
give
extension
analyze
on
the
minor
version
of
the
module?
But
we
can
use
this
configuration.
D
D
Because
use
a
route
extension
for
Magento
that
relies
on
the
minor
version
of
the
module
and
because
you
saw
that
this
module,
in
would
say
in
the
version
like
101
point,
has
a
perfect
started,
relying
on
the
configuration
option
and
then
salmon
install
this
extension
on
version
of
the
module,
someone
that
gets
version
of
module
101.3
and
he
doesn't
have
that
configuration
option.
But
because
you
might,
the
developer
was
able
to
install
your
extension
because
it
depends
on
a
minor
version.
D
E
Some
problem
only
in
default
value
because
I'm
on
here,
if
you
don't
defy
default
value
for
some
option
in
system
conspiracy
to
retrofit
and
request
it
just
retro.
No
for
you,
Elden,
making
optional
system
XML
is
back
what
in
camp
I
do
because
if
you
just
add
option
in
system
conspiration,
it
will
be
available
and
the
fault
value
will
be
new
but
the
same
whatever.
If
you
do
not
add
it
to
system
configuration
and
what
you'll
request
it
to.
A
A
D
A
D
A
D
Well,
schools:
it
might
be
missing
if
we
signs
at
the
extension
developers
right
as
their
extension
and
always
we
rely
on
some
edge
version
and
those
use
cases
covered
or
web
compatibility
and
missing.
Some
of
the
folks,
it's
extension
developers
would
not
have
a
problem
in
6/8.
My
extension
works
from
this
possible,
but
I'm
not
sure
that
they
write
extensions
like
this
I
think.