 Well, welcome. I hope you're enjoying the warmth. Pretty good. Well, since I'm getting antsy, I'm going to go ahead and just get started officially. So this is a point where they would probably actually start the recording when they cut it down later. So the session we're here today is Entities 101, Understanding Data Structures in Drupal. As I kind of mentioned before, data structures are really critical not only to understanding how Drupal works but also how to make really good use of it. I've seen people come in and do things not understanding how Drupal works that were interesting, but potentially really bad ideas, really painful. Someone was telling me yesterday that they saw someone that had created content types that had fields for different regions of the page, and they were dropping in just HTML in order to get things to do what they wanted, which is very interesting and really kind of defeats the purpose to a certain extent. So I put this together as a way to kind of talk about how structured data works, how entities work, now that we're kind of fully mature in the space with D8, and to do this from a level that's not overly technical. I think I've got one slide that has some pseudocode, but everything else is very high level. So when you come out of here, then you should be able to tell people very quickly and easily exactly what an entity is, exactly as a relative term. And hopefully you'll be doing so, and it should be fairly fun as we go along. So, who am I? Why am I here? Why should you even consider listening to me? My name is Ron. I work for Aquia Solutions Architect. Basically, that's a really fancy title for problem solver, quite literally. So I work mostly with the sales guys and girls, and when we're out in the field talking to people in large organizations about Drupal and why they should use it instead of proprietary platforms, my job is to do demos, answer technical questions, make sure that the sales reps are telling the truth, those kinds of things. And I've been using Drupal since 4.7. I actually got into freelance development for a while, had a small dev shop, left to go work for a company called Jackson River that has a distribution for nonprofits, and was a senior developer and tech lead over there for a while, and then I went from there to Aquia about almost two years ago. So, this is where I am online, if you ever need to yell at me about something. RL Northcut and R-T-H-C-U-T-T is pretty much where you can find me. So, if you've got that, you've got me. If you have any questions about anything in general, it's one thing that kind of blows people's minds in almost every single meeting I'm in. I give them my card and I say, hey, if you have questions about Aquia, let me know. If you have questions outside of Aquia about Drupal, let me know. Like, seriously? I'm like, yeah, seriously. Great. Because we're all in the same team. Okay, but before we go too far, what is an entity? Now, I'm assuming most everybody here has a concept. Has a concept of what entities are and what that means. But in order to understand where we are right now with entities, it's very helpful, especially for folks that haven't been around since four or five, to kind of understand how we got here. Because this wasn't like Drees woke up one day and said, oh, I know, we're going to make entities. Entities was a result of an evolution in the Drupal space over time. And a lot of people scratching their own itch and doing what they needed to do, grabbing ideas, doing different things, and eventually we kind of all started coming together and saying, okay, well, let's codify some of this and let's get on the same page because there's some inefficiencies that are coming from that. So going way, way back before my time in D3 and earlier, all you had were nodes. And nodes were pretty basic. There wasn't a whole lot you could do. In D4, we got this idea of flexi-node. And that's where kind of like the initial entity started climbing out of the primordial ooze. It's still not super functional, but now we're starting to get in the idea of having different types of things that store different types of pages and information. One of the big things that happened in D5 was the content construction kit. That kind of set off this whole kind of race where people were starting to really get this idea of making things fieldable, of actually being able to easily go in and create different types of content without necessarily always having to code. Because before that, if you wanted a specific type of form to create a specific type of content, most of the time you pretty much had to write PHP. And that's not the most friendly way to get into it. This was kind of codified a bit when we got into Drupal 6. And we got this concept of node types, as well as combining that with fields, still called CCK. And that's where things really started getting exciting. Because now, without having to touch code, you can go in and you can create different types of nodes. That's all we really were still working. We had users, we had text on, but nodes. And then we could add different types of fields to those. And it was very, very exciting. It was very, very useful. And again, people started finding all kinds of use cases and we started to node all the things. So content profile, node comment, taxonomy node. These are all modules in 6 where people were trying to kind of mash together the stuff they liked about fields and nodes into other things. And not the most efficient way to do things. It worked, it was a bit clunky. Sometimes it could be a bit gnarly when you got down to the depths of it. But overall, that was kind of very clear on where things were going. So in D7, which was kind of like a big step in maturation with regard to Drupal itself, we actually started this with entity API. Now, entities were available in core, but we didn't still have a fully robust API. It was still pretty basic. But entity API as a contrib module came out after, which was intended to kind of fill the gap and round things out. So a lot of times you would end up, and you do end up in 7, having to install entity API because it's required by something else that's relying on those things. But this is where we started to really kind of get this idea of kind of simplifying down and making everything entities. So users, terms, comments, all of those things became entities, and now because they were, we could start to use some of the same APIs like fields, and we start being able to add fields to things. So anybody that was here in 6, and remembers user profiles in 6, probably using something like content profile or profile node, and then coming into 7 with users that had fields. Does anybody remember that kind of being an aha moment? It was like, okay, now I get it. Now we're on to something. Exactly. So all of that was great. D7 is wonderful, still a great system, but now we have D8, and in D8 we've taken that concept and it's actually kind of evolved to be what the vision has kind of slowly become. And so that's kind of where we've come now. And again, this whole ramp as we've kind of grown through this process organically, we've started to see this, we started to get ideas, people started branching out doing their own thing, and then of course we all realized that that was just the direction everybody was going, so we needed to get on the same page. So quick little disclaimer. This is a little weird. Some people maybe, others probably not, but there are actually in 8 two types of entities. There are content entities, which is what most of us probably traditionally think about. So that would be nodes, users, terms, blocks, and then there are config entities. Config entities are what we're using for CMI, so we can export our configuration into code so it doesn't always live in the database. We're really just talking primarily about content entities today. So config entities is kind of another thing. There's some similarities, there's some differences. We can get into that later if necessary, but just for this purpose of today, just so that you understand that. So when you're talking to people about entities, and they say entity, then you can say, oh, are you talking about content entities or config entities? Because you know those are two different things. And then they'll be like, wow, I need to get the business card of this person. So this is the official definition of an entity. If you go online, you go to the entity API documentation. So entities are objects that are used for persistent storage of content and configuration information. Very nice, very clean, kind of boring. I wouldn't expect anyone to necessarily remember exactly what the words are for this. So I found another definition that's, I think, a little bit more friendly. And what I did is I went back and I found the original patch 2009 that Frando added a patch for entities. And in his description, he says, naming, in this patch I went with entity, which is a loadable thingy that can optionally be fieldable. And if you take nothing else away from this, then I hope you remember that an entity is a loadable thingy that is optionally fieldable. I do think it's interesting he says that, you know, let's not get caught up on the name. It's just something I came up with. We can correct that later. Obviously, it's still entity. So if anybody's got a better idea for what to call entities, there are a couple issues I can point you at and you can go argue back and forth all day long. So coming back around again, the reason we're here and what we're talking about, what is an entity? So let's break it down a little bit. An entity is a thingy. And I've got a nice little thingy that I created over there, kind of a visual guide. But basically an entity is just a piece of structured data, content like blog posts for an article, a user, a single taxonomy term, some other structured data. Now, this is where the terms can kind of get a little weird and I will forgive you if you are a little fuzzy with them, if you will forgive me if I'm a little fuzzy with them sometimes. But content broadly speaking is not an entity and a node is not an entity. It's a type of entity. But a specific article on space monkey jumpsuits is an entity because that is a thing. It is a single atomic unit of structured data. So kind of weird, I know, because we're talking about entities and entity API and types of entities and all of those things. But just remember, generally speaking, when we say entity as a single thing, we are talking about a specific single thing. In this case, an article on space monkey jumpsuits. I would actually read that. Okay, so entities are loadable thingies. So what that means is that we've got a common set of tools for getting that data in and out of the database. And of course, now with 8, we also have some common ways of getting it in and out of the system entirely. Some wonderful, wonderful things going on in that space. So this is the pseudocode. Actually, it's actually real code, but outside of the context of everything else. There's actually at least two or three different ways to do each one of these steps. So there's multiple ways to create or load or update or delete an entity. I chose the ones that were pretty easy to get and made a lot of sense. So as you can see, it's pretty straightforward. So creating an entity is as simple as calling a function, telling it what type of entity you want, and then adding the structured data into it. Now, obviously, you have to know what that data structure looks like. Good thing is we've got the UI to kind of abstract that out for us, and it takes care of all of those things. Same thing with loading. You just need to know the type and the specific ID. Saving is easy, because once you actually have that entity created, then you can actually call that method. And I just want to save this. Delete it, et cetera. And actually, if you look at the update, you could call an entity into being in code with that first line, or the second, if you know specifically which one. You can make changes to that entity, and then you can save it. Then you can go back, make more changes, and you can save it again, and you can keep doing that as much as you want. It's very lovely. Now, there are a few common properties across all entities. Every entity has an ID. It's got a little flag that tells us if it's new or not. And one of the, I think, most useful and most exciting things is that now that we have views in core, now that we have services in core, all of that is integrated with entities. So again, if you go back into some of the stuff in D7 or before that, before we even had entity API, when you were trying to, if you had some custom type of data that you were storing somehow in the database, and you wanted to be able to access that, you had to create your own integration for views, if you wanted to use views, and then you had to debug that, and then you had to maintain it, and when things changed or you found a better way to do this, because you went to a session that told you you had to go and maintain that. Now you don't have to worry about any of that. As long as you're following the API and you're just creating entities in the normal way, that integration comes out of the box. So actually, let's see a quick question. How many people here have created a content type in Drupal? Okay, most folks. And how many people here have created a view in Drupal? Okay, so basically you've done most everything here, whether you realize it or not, which is the exciting, fun thing. Okay, so this may look kind of scary. There's a lot of stuff here, but you don't have to worry about most of this. This is really more for reference. But again, remember an entity is a loadable thingy that's optionally fieldable. So you don't have to add fields to an entity to make use of it. And we'll talk a little bit about custom entities in a moment. But this is where we start to get down into some of that, hopefully clearing up some of the fuzziness around the language. So in Entity API we have types of entities, and those are those big, broad columns that we know. Nodes, users, terms. Entities of the same type all share the same properties. So as you can see, every single node, for example, has a node ID, a revision ID, the status that's published or not, user, title, etc. And so once you start to break that down, then those are the things that are going to be common across all types of that particular type of entity. Then we get into bundles. Now for a long time, especially in 7 when I was trying to start learning how to create my own custom entities, bundles kind of halfway made sense and kind of didn't make sense. But it's actually pretty simple. Bundles are basically like subtypes. So you've got node is your entity type, but then when you have created a new content type, and that's another fun thing, right? We talk about content types, but really they're node types. Those are actually bundles. So you've got bundles would be articles, pages, events, recipes, reviews, whatever your content type is going to be, that's a bundle. So you're kind of now starting to take, and you're getting down into more and more detailed levels of this structured data. There are some entities that don't have bundles, like for example the user entity. You're not going to have different types of users. You actually just have the one, but you can still attach fields to them. And when you define a custom entity, if any of you want to brave that new world, then you can actually determine if you're going to actually have bundles or not available, et cetera. So now we've gotten from the entity type, the properties that are common across all of them, down to different types of bundles which are subtypes. And this is where it starts to get fun because now we can take the field API and we can start to kind of add fields to each of those different bundles. And this is where that structured data starts to get, starts to fragment and get a lot more useful for us. Now one thing to note, and this may be interesting, this may not be interesting, it may be useful at some point, it may not. But up until we hit the field level API, we're really storing a lot of information about this bundle in the same place in the database. So if you go to the node table in the database, there's the node ID and the title and the status and the user ID and the created date and the posted date, et cetera, et cetera, et cetera. And all of the nodes have that information in there, but as soon as you add the body field or you add an image field, that's another table in the database. So I don't want to get too deep into that, but when you start thinking about structured data and you start thinking about the efficiency of your system, this is where it starts to get very interesting and fun because you can make some decisions which can make your life easier, potentially, or more difficult, potentially. You start talking about performance and scaling and all of these wonderful things. We'll touch on that a few more times, but I just want to kind of bring that out. Entity Validation API. So this is actually pretty cool. This is where if you create an entity and you stick the wrong type of data in or it doesn't match your rules, then the Validation API is going to figure that out before it tries to save it. This is what makes sure that most all of the time, obviously there's always exceptions, most all the time when you stick data into the database using entities and you pull it back out again, it's going to be what you expect. And sometimes that may not sound like that's that big a deal, but especially now that we're starting to talk about APIs and services and getting data in and out of other systems, you have to know it's the same type. Has anybody here done using feeds or using migration done a migrate or an import of content data in? And how many people have done it exactly right the first time without having to fix a bug? There's an extra comma and you go through and you're like 900 rows out of 1,000, you think you got it and then something throws up and you have to start all over again. Entity validation won't necessarily stop that, but it's going to make sure that the data we have going back out, once it has made it in, it should be clean, which you can then rely on it. So I'm not a designer, obviously. I'm just going to say that. I am a developer though, and so I break things down into boxes in my head. So this is what we were just looking at but presented visually because I'm a visual person. I'm sure a lot of people are too. So basically, very quickly, what we've already seen, we have the entity type, in this case we're talking about nodes. We have those properties and they're common across all. Then we have those different bundles, as you can see, they're lovely little colors. And then making use of the field API, we're adding fields to these bundles. I will point out those dark gray back and forth arrows. That just means that those are shared fields. So even though we have four different bundles, in this particular case, and each one has multiple fields attached to it, we actually only have five fields that we've added because body is the same across all of them, tags is the same across three, and hero image is the same across two. Now there are potential limitations to sharing fields. I won't go into that into too much detail, but this is where when you start thinking about structured data and data modeling, it's important to think about these things. Because if we went through, let's see that's 9, 10, 11, that's 11 separate fields potentially. So if we were creating a site and we had individual fields that were not shared in one of these, then now we've got 11 extra fields that have to be stored in the database. So now we have to have tables for those fields, we have to have tables for the revisions of those fields, we potentially have to have tables and they're related to anything else which might add something on from contrib space. So that can, you can see how, if you've got a large site with 5, 10, different content types alone, never mind all of your other entities like terms and users, et cetera, then the number of fields can just start to proliferate like crazy. So if you get to a big site and somebody comes in and they look and say, why are there 400 tables in this database? This is absurd. Now we're starting to hit performance problems. Then you go back and you see, well actually we could have had half that number had we been a little smarter about sharing fields. You shouldn't always share fields, but if there's a good reason, unless you have a good reason not to, you should strongly consider it. Good rule of thumb. So an entity is a loadable thingy that can optionally be fieldable. Is this all making sense so far? Good. Seeing some nodding heads, smiles, a few furrowed brows. It's okay, we'll get there. Okay, so awesome. So I know what an entity is. It's just a thingy, right? It's a base or stick back in. And hey, if I'm feeling crazy, I can even stick fields on there. And that's just really cool stuff. Well, so now you're going to sound like an expert because people love it when you say thingy, actually. But then how do we use this stuff? So we've talked a little bit about what entities are in core. And I just wanted to throw up a couple of examples. We've obviously talked about this. Entities are for content. So just straight up any content that you have in your nodes. Entities are for users, obviously. Collecting information about users and their profiles. Custom blocks. Has anybody used custom blocks in Drupal 8? Nice. A few people. So anybody in D7 ever done use the beans module? Yeah, fieldable panel panes. Okay, yeah. So basically the idea here is that in D7, you can go in and you can create a custom block, right? And you can drop whatever you want inside of it. HTML, a widget for Twitter, what have you. What about when you have, you want to create a bunch of blocks that all have a similar data structure? For example, you want to create a slideshow block. Now you can go into views, right? And you can create a view that uses a slideshow display to do it. And then you're going to have to have some mechanism for choosing which images go in there. Maybe it's a node queue. Maybe it's via taxonomy. Maybe you're just going to kind of cheat and just put in the specific field IDs that you want, you know. What custom blocks in D8 allow us to do is go in and say, I want a slideshow block. Great, now that's my bundle. Now I want to add a field to it and I want it to be an image reference. And I want to add as many of those as possible. And then on the theming layer, when I have a template that's applied, I want to take that list of images and I want to display them as a slideshow. Once I've done that, I, or oftentimes more importantly than that, the actual user, the content creator who's not going to be touching views because they would probably cry, they have the ability to go in and now create slideshow blocks as many as they want. And all they have to do is add the images that they want in there. And when they plop it on a page, whether it's with panels or they're just putting it in the regular block layout, whether we get some really cool stuff like Jesus was talking about, then it's simple, it works, it does what they want to do. And the really cool thing is, because it's fieldable, slideshow thing is great. I just go put in my images and it does it, but man, you know what? I'm spending so much time creating these images and putting the text overlay and it's always the same. Can you make my life easier? No problem. Now I'm going to go in and I'm going to actually add a text field for each one. So now you choose the image, you select the text field you want and then it prints the slide or we can actually do now. And... Sorry about that, guys. My computer is ringing at me. And we can do it a lot easier. So again, the same type of content, a concept of having structured content that you can reuse in different ways. We also have terms. This is one area where I think a lot of people have not fully utilized the power of taxonomy, the ability to go in and not only just organize data, I mean having tags and categories is great, but being able to put in actual information, structured data tied to that term, is really powerful. So for example, let's say you have a recipe website and you're adding ingredients and so this soup has carrots. Well, how cool would it be when you click on carrots and not only see a list of all of the recipes that reference it, which is pretty cool, but also to be able to see a picture of a carrot and nutritional information and where they're grown maybe tied to an API that's telling you if they're on sale or not at the... What was it, Gourmet Market? That's what he said. So this is where we start to get into this idea of very rich data but we're creating different types of data structures that have different rules and different ways of tying together and we're able to create some really, really complicated, really rich systems using these same tools over and over again. Same thing with comments, same thing with files. I cannot tell you how many times I've been in meetings talking to marketing people and once they get the concept that they can not only upload an image, but they can add information about it, like where it came from or what the usage rights are or when those usage rights expire so they can then use rules to go in and say, hey, if the usage rights have expired for this image, don't display it. Show the default instead. That's the kind of stuff they have to go through and do by hand now. And once people start to get the power of that it blows their mind. And so we actually have the ability using Drupal as this tool set to not only deal with anything, but we also have the ability to go in and know that we're going to be able to deal with things later on down the road. So I tell people all the time there's no way to be future proof because a year ago, I mean unless you were an engineer at Amazon, who would have known that the echo was coming out, right? But you can be future ready. So the module that does the initial integration for the Amazon Echo one of the guys on my team did it in a weekend. And the original version was pretty rough, let me tell you, but it was the kind of thing where because we had these common APIs and the common ways of doing things and all this stuff in core, it wasn't a huge lift. And this is not somebody that just has nothing better to do at this time but code. He's a manager of a team. He works like 50, 60 hours a week. He's married. He just had a baby. I mean, he's often I'll be on a video conference and he's got something right here because he won't sleep otherwise. So this is somebody who does not have a lot of hours in the day, but because he knows how to leverage these tools in such a great way, he was able to very quickly do some cool things. So let's take a quick example at this. Now I actually built this for myself in D6 way back in the day, project management system and I kind of had my own little dev shop. But let's take a look at what this might look like. So if you wanted to build one, you wouldn't actually go, you could go. There are project management modules and suites and things you can pull in, but you can also just grab Drupal Core and a couple of modules and roll your own. So for content types, different bundles you might have would be a customer or business profile, an actual project which would contain information about an individual project you're working on, and then specific tickets that came up underneath that describing what that's about. And those might have images or files attached or you might want to do something fancy with dates and times and Gantt charts and completions. All of that's totally possible, the question of time and how important those things are. Users obviously for people to log in, so both customers to see what's going on in their projects for them to add notes on problems they have for them to start tickets for developers to update the system and see what's going on. Custom blocks and custom views, usable page components. So I'm on this project page I want to see on the side a burn down chart of over time what is the estimated total number of hours what is the recorded total number of hours how are those matching up. As a user, as a customer I want to log in and see how many hours are being tracked against this project, how much is this costing me right now this very second. It's very easy. You create those things, you put them up and you raise care of the rest. Structured content like we talked about slide shows and hero banners using panels to do layouts and dashboards and all those kinds of fun things reusing the content in different ways. Vocabulary in terms you see this all the time on d.o. So we're talking about issues there it's very similar. Categories for projects how do you organize tickets if you're building it now if it's stuck on something you can work on it if it's in the backlog. Comments, some very cool things you can do. So for example on a customer profile or a business profile putting in notes about what you've talked about or things to watch out for you know don't ever talk about Game of Thrones with this guy because he's always two weeks behind and he will fire us if we give him any spoilers right. Adding comments and time tracking to tickets so you have a ticket that says oh create a new slide show custom block and the theming and formatting so that they can create slide shows on their Drupal site. Great, well now when I go as a developer and I'm adding a comment how great for me to actually have in there fields for the what type of work I did. I did theming work maybe there's a different rate for that or how much time I spent I spent two hours doing this maybe there's some attached fields or images here's a mock up of what it's going to look like my notes on what it is and over time if that my needs change I can just adapt, add fields take them away, change them all of this stuff is pretty flexible and then of course storing and managing project files because since files are a separate entity even though you can attach them into comments or attach them to projects or attach them to tickets you can also have a view which just shows you all of the files associated with this customer all the files associated with this project, all the files associated with this ticket all of those wonderful things and all of this you can do without really touching a whole lot of code if any at all depends on how crazy you want to get so let's say we go down that path and we do as much as we can with the entities that we have available in core and either we start to hit some limits or maybe we are doing some things that it just isn't quite a good fit maybe we are thoroughly obsessed with performance and we have this data and we want to make sure that all of that data is in a single row in a table we don't want it split across 12 different tables and have to do sorts and views and things so we might need to do a custom entity so the downside is it will tell you now how to do a custom entity at this point you are going to have to write some code the upside is that between some example modules that are out there between things like Drupal console I don't know if they allow you to do entities yet but I think it is on the map there are tools that make that easier and then of course even when you are creating your own custom entities you can still rely on the same user interface for doing everything else so you can actually get a whole lot of help you are 90% of the way there on a custom entity whether you realize it or not right now so why would you need a custom entity you might need something that is very very specific in terms of the type of entity that you need maybe those, remember those properties that are shared across all of them maybe there are some high level properties that need to be shared across all of those entity subtypes that have access to that for whatever reason maybe you have got some additional methods that you want to add not just save or delete or update maybe you have got some things like for example in our project management maybe when we add that comment we want to actually extend it so it actually recalculates hours and cost and charts and things maybe you have specific data or workflow needs and instead of trying to create that stuff with the entities that we have available it actually makes a lot more sense to kind of extend and create our own you might not want to use something that is existing so for example as we say here if you have a time report entity that is very similar to comment but you don't want other modules that you have in the site that interact with comments to affect it well now you can get a clear separation and create your own if you need total control if you want to extend your data model in ways that don't necessarily make sense or that are different basically at the end of the day any time it makes sense for you to have a custom module then you can do that and again the beautiful thing is all of that is possible with the entity API without having to do a whole bunch of crazy stuff so here is anybody heard remote entities so I have not had a chance to play with these very much I tried with remote entities for a project and it was a demo I was doing it very quick the idea here and I think we are going to start to see a lot more of this is that you create an entity structure within Drupal that gives you a way to interact with it so views can interact with it services can interact with it the caching system and other things however the data isn't in your database it's in some external service an API or another database or what have you and so there is this abstraction so Drupal has an entity and as far as Drupal is concerned this is all in the family it's like great I know entities I know how they work the difference is that when you are looking for that specific entity that is actually either coming from cache because we've already grabbed it and we have it here or it's actually calling out to that API instead of the database grabbing the data and returning it hopefully caching it and then doing whatever it's going to do sticking to view or what have you again I think we are going to start to see a bit more of this as the space matures and this is actually very exciting integrating with external APIs and sources without having to decide well I'm going to migrate or import the content well now I've got 10,000 recipes in my database and I haven't even started adding content yet now I've already got to upgrade my database server or I've got something very specific it changes a lot I need to be able to hit it quickly well now I've got to write some type of custom integration that knows how to do stuff but then maybe I don't know how to use views with that because I think going to save a lot of people a lot of headaches so something to keep in mind okay so I've been talking a lot I don't think we have too many people asleep yet so that's good but there is a very cool module it's fun to play with called erd entity relationship diagram buddy of mine wrote it and this actually allows you to go in and start to take a look at the entities and graph them out so this is actually the output from that so this is not one of my bad diagrams this is one of Drupal's bad diagrams it's actually a lot better so what you can see is we have these are content entities and we're looking at two different types we're looking at a landing page bundle and a basic page and we can see all of the different fields that are associated and some of those are properties because they are the same across all of the bundles node ID uuid etc and then some of those are specific so you'll see that we've got moderation state body etc and then of course we're also seeing that we've got references so we're referencing the user entity type from both authored by as well as the revision user ID on both objects and we're referencing moderation state which is another type of entity based on the workflow moderation that's in place take another look at another example here here's another example that's actually an article but also now referencing the tags which is a term and all those pieces fit together tags are related to vocabularies and terms are related back and forth this can actually get pretty weird, pretty crazy pretty complex but something fun to play with and also a really good tool to have in your toolbox when you're either talking about data modeling and you just spent 30 or 40 minutes quickly going in adding a few content types taxonomy terms and fields as a decision maker and say well this is how the data is structured does it make sense, do you see something wrong with it or something else we should do and then you show up with something like this and you're like whoa I just talked to you an hour ago and you've already done this, you're like yes I am that amazing and by the way I deserve a raise so making good use of those tools that we have so something good to know about alrighty so what is an entity look at that we're getting there okay so all together an entity is a loadable thingy that can optionally be fieldable is anybody think they're going to remember at least part of that after today it's the thingy part right that's what got me, like when I read that it was just like a light went off I was like that's fantastic okay so there is a there's a feedback form encouraging everybody to give feedback so that at the next con they've got a better idea on what things people like what they don't like so I don't know what that link is but please if you have the app or you're on the site feel free to do that and thank you guys very much question oh sure any other questions I believe they're going to be on the I'll update the page for this on the DrupalCon site and I'll put the link to the slides there any other questions ECK I've not played with ECK good stuff okay well try it out let me know entity construction kit I've heard of it but I haven't played with it