let's go ahead and get started great so
I'm Chris if you've seen me on
drupal.org I go by eclipse you see there
I do a lot of things that hopefully have
positively affected people's lives I am
one of the commentators for CTools
I'm a Drupal 8 contributor I helped I'm
like a subsystem maintainer for the
plug-in system and I'm senior software
engineer over Acquia specifically I
helped with our content hub product by
being the tech lead there and I'll
actually talk about that a little bit
this this session isn't a pitch for for
what we do there but a lot of what a lot
of what we do there informs this session
so there's like a lot of good kind of
interesting stuff there I have a
multi-year focus on page layout so I've
been heavily involved in things like the
layout builder panels panelizer page
manager for many many years now and I
also at this point have a multi-year
focus on data model replication
strategies and I'll touch on that just a
tiny bit as well during this so data
modelling if we're going to get into
this let's talk just a little bit about
it first question of course is what is
this and you know from a technical
perspective data modeling is a subset of
what we refer to as information
architecture but fundamentally it's
really just how do you store your data
where do you put your fields and you
know how is that data related from one
item to another so within Drupal terms
you're going to expect us to talk about
entity references indeed that's exactly
what we're gonna kind of touch on here I
have kind of a special a special way
that I like to think about interview
references that I want to kind of
communicate here but interview
references are really really powerful we
use them all the time
Drupal uses them
just baseline Drupal a lot there the
regular entities that are installed for
everyone with like a standard
installation have a number of different
interrelated entity references on them
and their power is due to things like
their ability to be data typed you want
to reference users you can forcefully
reference just users or if you want to
reference just articles you can just
reference articles they're multilingual
so we can have different references for
different languages of the same entity
there revisional we can have more than
one of them if you see this term
cardinality that's what that means in
short they follow the same rules as the
drupal field system does so we do things
like change references per revision to
with them where you know one version of
a node may be referenced a completely
different author so Drupal core does
this to where people who come in and
make changes to a node they're the
revision author not necessarily the node
author but we know that a particular
user was the author of a given revision
and we keep track of that over time we
also do the other way paragraphs does
this if there are any paragraphs users
where will reference a specific revision
of an entity so in two key reference
revisions does this and it allows us to
do things like tie current node revision
to a particular paragraph revision yeah
entity reference revisions module does
this and paragraphs uses that so having
said all of that I want to kind of
challenge some of the preconceived
notions here by telling you that in my
opinion entity references are also the
foundation of most data problems and I'm
gonna provide a couple of examples here
so I have an example for Drupal 7 and an
example for Drupal 8 so let's talk about
Drupal 7 Drupal 7 isn't ancient history
this point we're still supporting it for
I think well into 2021 so there are
still sites out there who are using
these sorts of approaches and the
particular story I want to tell is a
Drupal Commerce story now full
disclosure I've worked for Acquia for
almost six years now and I worked for
Drupal I worked for commerce guys for
four years before that so I have a lot
of experience with Drupal commerce and
I've seen a lot of interest and setups
there some good some bad
this one was not great and so in terms
of how they actually set this up I had a
customer who had of course stereotypical
product displays which are nodes in
Drupal 7 and product variants which are
a custom entity type and the
relationship of these things was such
that they also wanted to relate other
products together by saying oh these are
related products right and if you're not
familiar with what product variants are
just to kind of like level set on that
the product variant is like you can
think of it in terms of t-shirt sizes
you might have the t-shirt with some
graphic on it and you want to sell a
small a medium and a large version
they're all the same product but they're
different product variations right and
so in this case what the customer had
done was they had created all of these
different product variations and linked
them together based upon products that
were related and because of the nature
of their products they ended up with
over 700,000 different product
variations in their system and now
normally that would be a very large
profile of products but it wasn't in
their case for a couple of instances and
what was interesting about this was
because of the interrelated nature of
their data they could have single pages
that referenced as many as 64,000 other
product variants on page load that's a
lot
of entity loading to deal with all at
once and so in order to even get a page
up and running we had to do things like
set timeouts to be over 30 minutes just
to cache one page and then once the page
was cached you couldn't do any Ajax on
the page to do things like change
product variation because each product
variation load had to go through this
same sort of process and so it was just
absolutely positively not going to work
ever for them so I came in I took a look
at what was going on here and the way we
we fixed this was we actually just
changed some elements of their data
model and by doing this we actually got
a thousand-to-one compression of
variance we went from 700,000 products
to 700 products and so we did this by
moving fields that dentapreg affect
price off of variants and onto line
items and so if you've ever done any
Drupal commerce and you found yourself
with a ton of variants and not really
knowing like how to handle that one of
the little like tricks of the commerce
trade is that you know if you have
things that you might consider
variations but they don't actually
affect the price of your product any
those things can be put on custom line
item types and just even knowing that
this kind of data reshuffling is
possible is really really powerful to to
change kind of the nature of your data
model
so now I'm going to talk about a Drupal
one that most of you are going to be
familiar with the one degree or another
so hold this closure not a big
paragraphs fan I know that a lot of
people use it today and I think that it
has its place but I think that some of
the some of the ways that we're using it
as a community are actually really bad
practice going forward so one of these
is specifically around layout and as I
mentioned early on I have a multi-year
focus on layout and have helped to build
many of those tools so one of the things
that we see a lot with paragraphs these
days is people wanting to just use it in
order to to layout a page and so they'll
end up creating different like layout
bundles where maybe they have one column
and two column and three column
paragraphs and then they'll nest
paragraphs inside of paragraphs in order
to create more complicated layouts and
so it seems this a lot where we end up
with nested layout bundles with some
sort of data component sitting inside of
them and you know this customer that I
was talking with who had this situation
they told me that they had 50 gig data
tables just holding entity reference
revisions from all of the all of the
data manipulation that they had done and
you know if that's accurate I haven't
seen these tables for myself but if
that's accurate you know that's really
just an enormous table holding integers
and I'm actually going to kind of show a
demo of this here in a couple minutes so
is there a happy ending to this one
there's there's really not so much of
what we're doing around this today
results in an enormous amount of kind of
cruft in the database and there are
whole modules being built just to try to
clean up
through this and and kind of rectify it
but it could be worse at least we have
entity reference autoloading so
situations like the one that I outlined
in Drupal 7 they they can still happen
in Tripoli but you have to go to a lot
of effort to make them happen in this
case you know we we weren't seeing
things like that so while we're talking
about fields that reference stuff I want
to just pause for a moment and point out
that the entity reference field isn't
the only field that references things if
you're going to look at your data model
you need to kind of look at it
holistically and there's some things
that you can modify and some things that
you can't so I'll talk a bit about both
of those so obviously we have an author
field in the case of things like nodes
and I'm sure that you knew that was an
entity reference they also have taxonomy
terms and those are obviously references
to but did you know that every taxonomy
term has a parent and so if it's a
hierarchical taxonomy vocabulary when
you're looking at one term you could
actually be looking at a reference to
many different terms up to the stream
of course we have traditional image and
file fields we also have media
references which I don't go into it all
but it's like an extra layer of
abstraction from an entity perspective
around all of this and I know we're all
moving to it and I think that it's a
good thing to be using but people should
really be aware of exactly what we're
getting into here links link fields or
entity references at least if they're
done internally so if I have you know
one page of a site that references
another page of the same site and those
are done via entities then you know I do
a lot of data replication and if I want
to replicate that data it means that I
actually now have to reach completely
across a site to a totally what might
have seemed unrelated piece of content
and pull it across with just in order to
maintain all of these sorts of
connections as of Drupal 8 8 paths
aliases these are entities and they're
they're revision able entities so that's
worth knowing the underlying workflow if
you're doing any sort of workflow
management for your content these are
all introduced to
then layout builder I mentioned you know
I helped build layout builder and
underneath the hood layout builder can
reference a whole bunch of things like
it references blocks if one of those
blocks were a view that's an entity it
can also reference custom blocks so you
know Drupal has long had the ability to
create custom block types that you can
just put content in and this is actually
in many ways very similar to paragraphs
from from a data storage mechanism but
we have this as well formatted text this
one's actually my favorite because the
formatted text field most people don't
think about it as being an entity
reference but it actually is an entity
reference in many many different ways
because if you have if you have a text
for matter
that's a config entity if you start
doing things like entity embedding for
media or images or that sort of data
then your text could actually have many
different entities in it and so there
are lots of different ways that this
stuff is actually interrelated and
locked together in a meaningful way
of course the entity bundle field you
know your node type isn't just a string
it's actually backed up by a whole other
set of entities and I like to think of
these as being kind of invisible
references I'm also just going to take a
moment and say that I love that I can
use smaller text because we're all
staring at roughly the same sized screen
so invisible references what do I mean
when I say this well not only is your
node type also an entity but you have
form displays and view displays
underneath all of this that are also
entities and those you know you have at
least one form display guaranteed if
you're looking at a Content entity and
one or more view displays if you're
looking at content entity and when we
get into those they actually reference
field
config' field config actually references
the old storage and so it's it's just
kind of Turtles all the way down
so let's talk about a simple article and
I went ahead and I just put this one out
here all at once so we just can kind of
process this we've looked at a lot of
these fields already obviously a simple
standard Drupal article as it as it
comes out of the standard install
profile it's gonna have an author a
bundle the taxonomy term in the form of
tags image alias form display view
display field config and field storage
then it's gonna do all of that again for
every user image and taxonomy term
that's associated with this so if you
boot up a new standard Drupal install
and you go and you create a new article
with one of everything in it you're
gonna have somewhere around 40 entities
as being dependencies of that one piece
of content okay
and I think that's really important to
kind of understand because if in three
fields we can escalate to 40 entities
you know how many more are involved in
the complex data models that we build
today and should we really be
considering what it means to build these
data models
so I'm gonna take a couple minutes and
I'm gonna pick on paragraphs we already
know that I'm not a big fan here but
let's at least define what paragraphs is
paragraphs to me is a simple entity that
holds field data and is revision able
okay it's really useful for like
grouping multiple fields together so you
know I have a little example here where
maybe you could imagine on a node you
want to have a list of users and what
Department they're in so you might build
a paragraph that has two fields on it
one they use a reference field and
another a Department select list right
and you could potentially add as many of
those as you want and in this sense it's
actually really useful for building this
sort of data modelling because building
cum compound fields like this in Drupal
is actually a very difficult sort of
task the community however makes use of
this parlez out and I've touched on this
a little bit already so we tend to
create bundles with references to other
paragraphs and then each of those
references becomes a column in some
template layout that we're going to do
and we start nesting these together to
make more complicated layouts okay this
is very stereotypical I've seen this out
of Acquia I've seen this like out of
almost everybody everybody's done this
at some point
and underneath the hood entity reference
revisions is storing paragraph revision
IDs and it links this stuff in a parent
to child revision strategy right so if
you have node revision ID one it's low
it can be referencing a paragraph
revision ID one or you know as you go
forward changing new revisions you can
get new revisions of each thing here
unfortunately
Drupal can't tell when a user has
actually interacted with its field or
not so if you hit the edit button on any
page that has that has paragraphs on it
and you just hit safe you're gonna get a
whole new set of revisions each time so
it's needlessly creating these in the
background I'm actually going to show
the demo of this just so you can kind of
see exactly what's going on here
ultimately this adds a ton of cruft to
your database and its complexity that
your data model has to rectify at some
point in the future right this is kind
of like where we bury the bodies so why
don't I figure out how I'm going to demo
this on two screens give me just second
you
okay that's
that is going to be a little big
you
and of course now I've lost it alright
here we go
can everybody see that okay yes awesome
alright so let's just make sure my
servers running good servers running
okay so I went to the effort of going
ahead and just creating some very simple
stuff here so I'll quickly kind of show
you what I'm doing I have a paragraphs
page bundle for nodes and if we look at
that it's just got one field on it for
paragraphs and it can reference any of
the paragraph types that I've made then
if I come in here and I look at
paragraph types you'll see I made an
image links of text and then I made a
two column layout here so while I'm at
this I'm going to get one more thing
together
okay so this is sequel pro this is
sequel pro for the site for staring it
so I just want to look at paragraphs
here so that you know there's there's no
magic going on here so we have paragraph
item revisions field data and paragraph
item revisions so we'll come back to
this in just a second as you can see I
haven't created any content for this
site so let's go ahead and fix that and
I'll just make a new paragraph page and
this will be you know who and we're
gonna add a two column to it and on the
left on the left I'm going to add text
and then on the right I'm going to add
an image
you
oh and if I hit save on this we're gonna
end up with about what you'd expect we
have a paragraph that says this is a foo
the image here.
And if you go to SQL pro, we have three new paragraphs in here and we have various field data. And I'm going to try to open this a little bit to maximum on this screen.
And, you know, this is simple. This is three paragraphs on a page, and anybody who has done this workflow before with paragraphs knows that you are going to end up with dozens under most circumstances.
And so if I just hit edit, and then save, again, so I'm not actually doing, if I come over here and refresh, we have six of these revisions. And you can imagine, if we start nesting and nesting and nesting data together, this can get really nasty, really quickly. And we don't even have to go so far as contriving a situation where we are hitting edit and save. If you want to edit the data, you change one value of the paragraph and hit save and all of the paragraphs on that page got new revisions in the database. All of them, except for one, needlessly.
And this is just kind of a shortcoming of how the field and field API systems work together in the first place, it is worth knowing that this is what is happening underneath the covers of paragraphs when you are making use of it.
Let's see if I can go back to my presentation.
Cool, can everybody see the presentation okay now?
>> Yes.
>> Yes.
>> Cool. So I have ragged on paragraphs a lot, I'm going to do a tiny bit more and then we will move on. Under most circumstances, paragraphs would actually be better served from a data modeling perspective if you didn't use it, and instead went to the effort of building a custom field type.
And there are far fewer entities involved when we are doing that, because you really only have the entity that you're attaching the field to. There is no new entity, you are just writing the plugins to do the work. This is a superior data model 99 percent of the time. There is an outside edge case situation in which paragraphs is the only solution, but it is very, very uncommon. I have literally seen it once in my career.
And unfortunately, this is a whole lot easier said than done, building a new plugin custom field type is not that trivial to do. It takes a little bit of effort, a little bit of know‑how, and probably today in the current Drupal climate, if I, you know, was a ‑‑ was involved in a site build and I said to one of my developers, hey, why don't you build a custom field type for that, they would say, why don't you just use paragraphs. There are things we need to rectify as a community. One of the big things we can do is by making this process easier. I have some thoughts about that, but it is for a completely different discussion. Ultimately, though, the objective at looking at custom field types, this is data, there is no layout information.
So we will talk about layout builder just a little bit. It is important to touch on it, I don't want to pick on paragraphs the whole time and not provide any alternatives or any reasoning for my alternatives. So in cores these days, I encourage you to play with it.
And much of what was said in the previous slide, it is usually a whole lot better if you can build a custom field type for the data you want to store. This is how layout builder stores the layout overrides. So in layout builder, if you wanted to let each of your node articles have its own layout, we do this via field data. So we actually deploy a field to the node and that field now holds layout data for the node. So we are leveraging custom field storage here and under the hood we use layout and blog plugins in order to visualize what is going to be on the screen. And we can use content blocks, they are like a defined paragraphs, they are a simple, revisionable, fieldable content type default in core. If you have created new content and placed it somewhere, that is done with content or custom blocks, these are often interchangeable terms. So it is very similar to paragraphs, and the important thing to keep in mind about how layout builder does this, it deploys its own userface for all interactions with entities appearing there. We are not dependent on form and field API in the way that paragraphs would be, we can tell when the data is changed and we make updates as relevant, there is less cruft and since there are no extry entities to define how the data is stored in the first place, it ends up being generally cleaner. And also, if you are wanting to control the layout, I generally think it is better to have some sort of visual aid for that and layout builder is exclusively trying to show people what their page is going to look like when they're done. So as a visual editing tool, I generally consider it to be in a completely different category. So let's take a couple minutes here and talk about Drupal data modeling best practices, and these are my best practices, and I'm trying to pass on a little bit what I learned here. These are my guidelines. You should limit the number of related entities, as we dig into the bits that we're going to show, you will see why I think this is really important. But I hope some of the examples I have given help hit this home. The more entities you have collaborating together on a screen, the more over, you know, there's a cost for doing that. Don't use data modeling tools for page layout. I'm specifically calling out paragraphs here, paragraphs is a data modeling tool and when used a lot of the problems we see with it are largely mitigated. When we use it as a layout tool it complicates the situation dramatically. If you are going to use paragraphs, don't nest them. Again, there might be a handful of situations where that is necessary, but if you can avoid it, I would heavily encourage it. And finally, custom field types are always greater than paragraphs, if you have the technical expertise to build custom field types to hold your data, it is a far better place to be than having the data model that paragraphs is bringing along with it.
So, I've talked a lot about the underlying data modeling principles that we have here, but I want to talk a little bit about when and where we reference things. Because this is one of the unseen choices we tend to make and we tend to make it incorrectly. So keep in mind, with everything we are about to say, there are always tradeoffs. It doesn't matter which approach we use, there are going to be pros and cons to all of them. The two most obvious approaches here are parents referencing children, and children referencing paragraphs ‑‑ ha, parents.
For reference, paragraphs kind of does both of these things. I will talk about that a tiny bit, it is just worth noting. So let's talk about the first one, parents referencing children. This is fine under most circumstances if you are doing a one to one reference. If you have a parent node that needs to reference a child node and it needs to do that once, that's probably fine. It doesn't really matter where you put that data.
But the second we start considering a situation where we want a parent to reference many children, there's a whole host of questions you need to stop and ask yourself because this can get dicy really quickly. So first question that I think people need to consider here is how long are these references going to exist? And so I'm going to kind of contrive a project management tool for the sake of this conversation. If you can imagine having an organization that references projects and projects that references tasks, this is interesting quickly. If you are sitting in your Gira queues and dealing with stuff in that way, you don't want to go and look at your project and see a thousand different tasks as part of the referencing of fields in there, right?
So how many references are going to be there, are we going to archive references over time, what does that look like? And there are UX considerations that need to be made here. If we're going to do this, what is the UX of it going to be? This is the most obvious approach to doing this, and the Drupal community at large has built many tools around doing specifically this.
And if you have ever dealt with in line entity form, which was built in order to help futillitate how Drupal commerce does many of the things it does, this is specifically the expectations that it has in order to work.
Dan, do you want me to address that now, or should I hold it until the end for questions?
>> No, until the end.
>> Okay, cool. It is also the most dependency encumbered approach, I keep saying I will talk about that, but I will. When you have a child referencing a parent, it is naturally one to one almost always. There may be some very strange circumstances where a single child might reference multiple parents, but that is not super common. The more common thing is sticking with the project management example, a task can say this is my project. And we have the same relationship in the other example, except there is one field to fill out and there are not multiple values ever. And if you are going to do it, you have to set up queries and views in the Drupal sense to display at the parent layers to get the interrelated tasks. And I generally consider this UX to be simpler, there is more code to set it up properly and I will demo that here in a couple minutes and the dependencies for it are much simpler as well.
And also things like my example of archiving, this usage over team can be accounted for by the queries and views that you build. So if you want to show all tasks that are not currently archived, that's a view you have probably built some version of in the past.
Paragraphs, as I mentioned, does parent/child relationships. This is obvious and how you interact with it. And it has fields for parent type and ID if you look at the schema, if you are interacting with it from a PHP perspective, it has nodes to load those parents. This is really important for my use case, when doing data replication, I have to know this stuff. If you edited a paragraph, I need to make sure the chain of dependencies is in tact. And this is just field values ‑‑ that is good and bad depending on how you want to look at it. I'm just calling it out here. In case you ever need it, know that paragraphs does have this reference. I'm going to speed up here because I'm running towards the end of my time. There's another topic I have not covered at all, when to create a new entity type. And if we are talking about data modeling, we have to acknowledge that you are not stuck with the existing entities, you can create your own. So a few things worth noting: You should only consider this if an existing entity type does not suffice. That's my doorbell.
So ask yourself some questions. Is it stand‑alone page? It might be a node. Does it display many other items together? It might be a term, or a view.
Right?
Is it used on many pages independently? It might be a block, right?
So whatever the case, just make sure that if you're building a new entity type, you have specific special criteria that no other entity type is matching for you.
I will, however, throw out a quick warning that if you are going to do this, everything we've talked about up until this point is possible to happen on your custom entity types as well, if they are a typical content entity that is fieldable and bundlable and revisionable.
So why do I know all this?
As I mentioned earlier, I'm the tech lead for Acquias content hub. And content hub, we will have plenty of time for questions, thanks Bob.
Content hub is a tool that does data replication, okay?
So we released the 2X version of content hub last year sometime. And what we have to do with this tool, since it is a data replication is that we need to identify all entity dependencies of any given entity. So that example is, like, a simple article that I gave earlier, that's a real example. I ‑‑ it is not hypothetical, the software that my team and I write and maintain actually has to have the capability to navigate through all of that, find all of those dependencies, and put them in some sort of format that we can communicate from one Drupal site to another. If we cannot do that, we cannot succeed at our job. Right?
So we deal with data models all the time, and some of these data models are very simple, and some of these data models are very complicated. Sometimes the customer wants to dynamically re‑sort their data models as they syndicate them and that's a whole different ballgame.
So what I want to do is I just want to kind of demo a couple of those ideas for you, and then we will open it up for questions and we can go from there.
So let me grab my other window.
So I mentioned earlier that we can think of things in terms of maybe a project management tool, and so what I actually did here is I went to the effort of building out, like, a really scaled down version of these two competing data model ideas so that you can see what they were doing underneath the hud.
And let's start with data model A. So if I come in here, I have an organization, Acquia, that has projects of Acquia content hub. If I look at this, you can see exactly what I expect it to be, in line entity references, yes, maybe I could have set things up better, because these are auto collapsing, but I have 1s and 2s of things. So it doesn't matter for my use case. So you can see, I have the reference to my project, if I click into the project, you can see that it references three tasks I can do. So we have an upcoming release here in the near term future for ADAX2.12. So I have this blank task for it. And this is, again, very stereo typical. If I look at the project, it has three tasks under it and I wanted to add another, I could. And many people are using a model that looks similar to this for layout or page paragraphs, using in line entity form, complex where they can start collapsing things and they have, like, individual edits. And these are all going to be good things to be doing if you are going with this approach. And knowing that, I have a term in the window here somewhere.
And of course, zoom is over it.
Sorry, hold on a second.
So I'm going to use a tiny bit of the tooling that we actually built for content hub here. So I will grab this so you can see it. No session is safe. I have to get technical at some point. So within what we do, within content hub, this is technical details, we actually want the ability to move data around. So what we do, in order to simulate this, I have commands that let me build a manifest file that says, hey, I want to export the node we think of as this new UID and all of its dependencies. This is model A.YAML and I run the command and it gives me this. And this is a great, big, JSON value for every single entity that is required in order to make model A work. And you can see if I scroll through this to the bottom, this is 2,800‑plus lines of code, or of JSON definition in here. And this tells us about the interdependencies and it has the raw data in here and it tells me what fields are associated for each thing. The config entities are in here, all of this is sitting in here for me to play with. And I also wrote myself a little count script so I can see what is going on here, that's what we're going to do. I will count all of the individual items in the model A JSON. You can see there are 37 different entities collaborating together in order to make this happen. And why is that less than the articles I talked about? That's because these are simple data models, they don't have a value or sort to them, they are dependencies. So I'm asking for the org, I'm asking for the organizational node, and it navigates down into the project because there's an entity reference there and then it navigates to the tasks because there are entity references there and it pulls all of the data across. To re‑create that organization from the perspective of where I spend most of my time, I would need to pull across all of that data. Now let's go and look at the other example. I have these model Bs, and as you can see, I have an organizational model B for Acquia in here as well. I stuck a view in here, because I didn't have field references. If I hit edit, it is just a title and body. There is no entity reference here. If I come into the project and we edit it, you will see that it has a reference backed to its organization. Okay?
And if I come to any one of these tasks, and I edit them, you will see they have a reference back to their project. So all the way down, I'm building this relationship back up to where I started.
And there are things that are not as easy as I would like, obviously, because I wanted to actually create administrative details of this since I no longer have at my disposal in line entity form, I have to be savvy about this. And this is where as a community we can come together and build some tools for this. In Drupal6 and 7, I had tools for this and did not bring it forward to 8. And you can see that it auto references Acquia, if I have a project, and it is the same sort of thing. It is referencing my problem automatically, I cannot edit it. It was passed along my url here. And so you can see that it is node 7 add task. So that is kind of how I'm structuring this to make it work. And then the visualization is coming in through views, you have to do it since there is no field reference for it.
And I will do a quick compare and contrast here. We also have a model B YAML, which is referencing that ‑‑ the org node, it is referencing the model B org node. So in that case, if we look at the JSON here, you will see that this one is actually about half as long. It is 1,300 lines, and there's really very little difference between these entity models, except where I chose to place the references and what those references actually imply and mean.
So think of it in these terms. Can an organization stand alone without its projects? Yes, it absolutely could. That is meaningful on its own. It is isolated in such a way that we understand it. Could a project stand alone without its organization? Probably not. That would be confusing if it could. The dependency in terms of, the human level of communication implies that the project needs to know about its organization, not the other way around. And so I will do the count here really quick. And having said all of that, I will come back to the session here. We will open it up for questions. Dan had a question I want to go ahead and address first. So Dan, I will read your question. Can you talk about custom field plugins more and if and how they would replace the groups of the field patterns that paragraphs use, such as a list of call‑out entities that include header, field, and body fields. So I'm probably not going to get all of that perfect, but obviously we can build custom field types and those types can have whatever normal promatives we think of as the fields today.
So in that sense, what do you mean by a call‑out entity?
>> Sorry, I can use the thing ‑‑ if you wanted to do that una custom field type, where you have a project with a field and it had a couple fields on it, a couple text fields in it.
>> Right.
>> Yeah, so the thing to keep in mind, I guess, cardinality answers a lot of these questions. If you look at something and you say, like, let's use my users and department example from earlier.
If I have a list of users and the corresponding department, we can conceptually conceive of that as maybe we have as many of these as we want, it is an unlimited field value. That is okay to consider. But if we're going to do that, we want to know, like, is it ever unlimited within the field values? Could a person exist in multiple departments? If a person only ever exists in one department, then this is a unit that you can build as its own custom field and it is sensible. If we start getting into things, like, you say header here, and I'm maybe conflating that with layout, do you mean something about layout here, or no?
>> No, so sorry. I was not trying to make it complicated.
Let's say you have an article and sections of an article and an article has an image and text or whatever, there are multiple fields and you can have any number of them on the article page. The order is what the order is, but the layout is not important. Can you have the image and the field be a single field and a name? Is that what you are saying, when you say a custom field type?
>> That's exactly what I'm saying. If I have data that looks like it goes together, if you would build a paragraph and associate multiple pieces of data, add multiple fields within that bundle, you can stop and say, should this be a custom field?
Because there's a significant possibility the answer is yes. If you are doing that, you can actually just deploy the field to the entity and attach it directly and you will have a cleaner data storage for that. It will deploy two tables, one for the field and one for the field revisions if the field you are adding it to is revisionable and you are only storing the data that went into that field and you are only modifying that data as you interact with the node.
Does that answer your question?
>> Yes, there are other questions. I can figure out the details right now. But yeah, I was not aware that is optional.
>> Okay, cool.
>> We have a couple minutes before the session close here.
>> How many?
>> About three minutes for our session ending here. There's a couple of questions that are on deck in the chat. If people have further follow‑up, you can ‑‑ we can take it over to Slack for that, or use one of the rooms that is not being used right now, like the hallway chat.
>> Yep.
>> So there's a couple of those questions, do you want to tackle one of them?
>> Um, yeah.
I'm going to paint with a broad brush store here, David, which I know is probably not good enough. We should be looking to look field composition easier within Druple core, so you don't need something like paragraphs. So I guess what I'm saying here is ‑‑ and this may touch on the next question, you are asking about multi‑field in seven. We should probably figure out how it is that we can generate new field type plugins without generating content entities to store all of their data, which is what paragraphs does. There is another way to go about this that would be more raw in the data sense.
And that's the world we should be looking towards. The project management tool stands, like, this is a thing that people should be aware of, the decisions where we put reference fields matters in the long term and you are looking at that with your approach as well. I will run through the last two slides and then I will hop over to hallway chat for anybody that wants to engage. Please provide feedback, top rated sessions are going to be captioned. You can find mine at this url, which is not easy to click. And please come to the contribution day on Saturday. Many of you have done that for a long time. It is great to see this continue to succeed, even in a virtual format. Thank you for your time. I appreciate it.