 Okay, so welcome everyone to the session about Triple 8 entity API. I hope most of you guys made it up here. It wasn't easy to get here up from the keynote. So my name is Wolfkentzikler, or Fago is the man in the Triple community, or I'm the real Fago on Twitter. I'm a Triple developer based in Vienna, Austria. And I'm the maintainer of the entity API module, as well as commentator of the entity to inform core components. Yeah, I'm also maintainer of various counter modules like rules, field collection, approval too. And I'm the CEO of a small Drupal shop based in Vienna, Tonomics. So in this talk, I'll talk of course about the Triple 8 entity API, and we'll start with a short little bit of history of the entity API in general. And then I'll introduce you to the new API and demo how you can work with entities and fields in Triple 8, and you'll also see how you can provide a new entity type. And then I'll shortly cover some new APIs around it, like the entity validation API and the new entity query API as well as configuration entities. So let's get started with a little bit of history. Entities in Triple 7, they really were a side effect of the field API being decoupled from nodes. They were introduced rather late in the cycle. Field API was introduced earlier, but we figured out just really late in the cycle that we also need the concept of entities underneath. So the entity API in Triple 7 really ended up being basically unfinished. So the way around it actually is the entity module which I've created. You probably know it, the entity API module in Triple 7. Complement a lot of the missing functionality of the entity API in Triple Core. And yeah, it's a good way to work with, but it's not ideal as it really has to complement what Triple Core provides. So in Triple 8, really our mission is to make it better out of the box and to have a complete fully working entity by integrating in Triple 8 Core. So we've been working a lot on that during the last years and we pretty soon already got to have class-based entity objects in Triple 8 Core which are based on defined entity interface and we also pretty soon got full grad storage controllers. What means your entity storage is out of the box capable of not only loading entities as in Triple 7, but also of saving and deleting entities. So, but then pretty soon we also figured we had also had a lot of discussions about what and for what to use the entity apparently. So in Triple 7, I think a lot of people are thinking of entities mostly of the content of the Triple side, but then for Triple 8, we actually figured we want to make all the things entities. So basically everything that you can store and load in Triple 8 is an entity. So it's not only content, it's also the configuration objects of your site. When you like create a node type or you create a few, those are all entities as well, configuration entities. So we really have two sort of entities. So we have two flavors like we have the content entity flavor and the config entity flavor. They all are based up my common interface and the common API, the common entity API. But then we have some extensions which are special to like the only content entities or the only configuration entities. Okay, so let's have a look at how you can work with entities now in Triple 8. So as most things in Triple 8, it's all object oriented. So to get started, you really need a service. You've got an entity manager service which is really the central point of the API. And it's the manager has a lot of methods which allows you to get other dependent objects which then help you to deal with your entities. For example, if you would like to load an entity in Triple 8, you should get the entity storage of your entity type in this example, the comment. And on this storage object, then you can call the load method to load the entity. There's also a shortcut for that like on each entity class, automatically a static method like here load to load an entity. So you can just use comment load and the ID but which obviously doesn't work within a dependency injected object. So if you are working in a class in Triple 8, you should use dependency injection and dependency inject the entity manager or the entity storage. But if it's just like you're implementing a hook and a module and you don't have anything injected, you can just use the shortcut as well. There's a similar shortcut like for creation. As in this example, you can see, you can easily create a user object by just passing some values for the fields and you'll get a new user object. And then each of the objects as said is based upon a common interface, the entity interface and it has some useful methods on it like to get the entity label, entity ID or stuff like the entity type. Then for accessing fields, we actually have a fully-fledged new entity field API in Triple 8. What means for accessing the value of a field you don't have to use like the complicated square brackets, language non-zero value stuff as you know from Triple 7. Okay, thanks. Yeah, so you can easily just access like field name, value and that's it. And if your field is multiple, you probably also want to specify which field item you wanna use. So of course you can specify that as well by just using the square brackets to specify which one. That's actually optional. So if you don't do that, it will automatically use the first field item to access the value. Yeah, and in this example, we are actually accessing the target ID of the term reference. So be easy and straightforward. Then of course there are also some methods that make it easier to deal with the fields in an entity like can ask an entity where it has a field with a certain name. And also the field items are objects as well. They also have defined interfaces and also useful methods like on a field item can just ask the field item to give you the entity on which the field item is. And to update field values, it just works with the same fluent API, just add a new value and save it, you're good. But apart from that, we have also been trying to add really methods to entity types that are entity type specific and that makes sense to certain entity type like for nodes, nodes have special functionality like they have publishing states, they have created dates, they have offers, folded kind of functionality. We have also added methods. So when there are methods for those base functionality for entity type, you should use that instead. It's best practice to do that. And if you're providing an entity type, it also makes sense to provide meaningful methods with your entity type as well. Just as an interface for those, of course. Then you might have noticed the neat way to access the field values completely misses the language. That is because the translation approach in Drupal 8 works from there different and that you once get a full translation of your entity object. So when you have an entity object, originally it always uses the values as input by the user. So it always goes with the original entity language. But then you can, on the entity object, call the getsTranslation method pass the language code and you will get back a full copy of the entity language with all the translated values in it. And then you can use that copy to just use the translated entity fields. Then access the title of a node and it will be translated. You can just access it the same way as for the regular node. Then as I've shown here, of course, you can use the same methods on the translations as it's just not instance of the same class. And if you ask it about its language, it will tell you the language translation it is in. And then there's a very convenient method on the entity manager, which is called getsTranslationFromContext. And this one actually will make sure to give you the right translation to use for your display context. So when you are displaying something on your side, it will figure out the right translation to get you to use based on the language folder calls. So you can just use that method. You get back a translation with the language folder calls applied and use that translation for outputting things. And of course, finally, when you have a translation, you can always get back the original entity object where calling getUntranslated method on it. Then entity types really got promoted to a domain object in Drupal 8. That means instead of having that huge array of hook entity info and a lot of keys you have to know in there, we now have a glass object based on an interface which just has some convenient methods on it you can easily use to access all the settings of an entity type. So when you get the definition of an entity type, the entity manager, that's basically the equivalent of retrieving entity info in Drupal 7, it will give you back the entity type object. And then you can use the methods on the entity type object. You can ask it which entity keys are defined or whether it's content configuration entity and stuff like that. All the settings are in the object. Then of course, you also have a way to ask the system about the fields that are defined for an entity. And that is actually working with so-called field definitions. When you have an entity, you can just ask it about the field definitions of all the fields that are on the entity and it will return the field definition to you which actually is another object based on another interface. You get the pattern. And yeah, it has convenient methods. It's really the equivalent of the structures that you know of the field API in Drupal 7. But it has been improved to a new and unified API, the entity field API. So you have got field definitions which tell you all the information about the fields like its name, whether it's multiple or not, which properties are in it. Of course, the field type, stuff like that. And when you don't have an entity object yet, you can ask the manager and it will give you all the field definitions of a certain entity type and model combination. So what's really nice on Drupal 8 is what Ries already mentioned in the keynote. Everything on Continent, it is now, is the field. So like note titles, not graded date, or what traditionally in Drupal 7, we're entity properties. Those are fields now as well. So it's really useful because now we have a really unified way to deal with the data and entity. So you can easily just take an entity and iterate over the entity object and actually give you back all the field item lists. And it will just have a common API, a common interface for the field API fields as well as the fields that come with your entity type. So all the field item lists are based, objects based on the field item list interface. And over those you can iterate as well and you will get to all the individual field items and those are based on the field item interface. And then the individual field items you can use, of course, to access the individual field item property values like just the value of a text field or the target ID of an entity reference. So as you might think, we now have different flavors of fields still a little bit because a field that's defined like in the interface still behaves a little bit different than a field that comes with a module. So for that, we now have the concept of base fields and bundle fields. So the base fields basically are what were the entity properties back then in Drupal 7. It's like the node title, node ID, user name, or the user rows, those would all be examples of base fields. And what's common to that is that those fields are each instance of an entity regardless of the bundle. Like when you have a node regardless of the content type, those fields are always on each node. But then the bundle fields, those fields are really bundle specific. That means that they only appear on the entity type and bundle combination for which they have been configured or to which they have been assigned. Yeah. So the question was whether all entities now should define a bundle even there's a single one of them. So the answer to this is yes. That's already sort of the way you have to do it for Drupal 7 for being able to use field API. It's not like it's strictly required but you really should do it. And we might get there to do that automatically for you if you don't define it. So that shouldn't be a big deal. But yes, all the field API fields, as mentioned, they really are bundle specific. So everything that you configure there is related to an entity type and bundle combination. So configurable fields already used that term. It's actually the term we are using now for field API fields. So everything that used to be field API, we just code now configurable and it's still provided by the field module. But the difference is that the field module now integrates with a more common entity field API. So those fields are just a certain flavor of fields which are actually managed and backed by the configuration system which the field module takes care of. And those fields also of course appear in the UI by default and just implement the same interfaces as all the other fields. So it's really just the management and the configuration that's special but it's all the same as for the others. So fields-dutch definitions is a new concept we introduced rather recently. Also it's very easy to get when you have the analogy to Drupal 7 field API. Like field instances, it basically is what in Drupal entity field API are now the field definitions. Those are really fully working fields which are complete and you can use it SDR like we use widgets and formaters with it and everything. But then there's also the field config which is really just the definition of the field storage of the data bucket that's used to store the values of the field which are shared across all the bundles. And the field storage definition really is just the general entity field API concept of that. And there's also of course a method the entity manager to get to all the field storage definitions of an entity type if you need that. And finally we also have module-provided fields now in Drupal 8. All I mentioned field module is one module that provides all the configurable fields based on the configuration management system but really you could write a module that provides each own fields which are not backed by config. So you can just implement one of the hooks like you can implement hook entity bundle field info and define another field for an entity and bundle combination. It's really the same for hook entity base field. You can add further base fields to an entity for that and hook entity field storage is really just for field storage definitions. Finally of course, when you have a field definition you can ask it which module has provided that. So speaking of field storage, field storage got moved into the entity storage so that's not a separate system anymore. In Drupal 7, entity storage and field storage really were separate independent components but they figured that doesn't make a lot of sense so we moved the field storage into the entity storage but actually makes it much easier to implement a new storage engine because you can just swap out the storage for a whole entity type as a whole by swapping out the entity storage and you don't have to swap out multiple components. So the entity storage takes over field storage even for configurable fields but you can also define a field with custom storage what means that you as a module would have to take over storing the data of a field customly. And then finally, there are also fields without any storage that are so-called computed fields and the computed field actually just allows you to compute something when it's accessed on the fly. So it's like just a magic field item property that when you access it, the value gets computed in the back and that's it. So there's no storage behind that. Huh? Refuse? The question was whether the commuter fields work with views? And no, I don't see how that would work, but no. That's actually, there are not many examples of commuter fields in Drupal 8 Core. It's like those two examples which I have on that slide are the only two I know. It's actually the process property of a text item is basically just the text format apply. So it computes the output of the input to text applies to text format and it's just the final text ready for output. So you can get that by just accessing the processed computed property. So you don't have to use the text sanitize function which was in Drupal 7. Then also very convenient is when you are dealing with entity references is that those references also have a computed entity property. So in addition to the target ID field item property which we have already seen, you can just use dash entity and you will get the fully loaded reference entity object and just continue working with that and change flow. So that's very convenient when you work with entity references. Yeah, so I've talked quite a bit now about fields. So you might wonder how fields actually relate to configuration entities. So all as mentioned everything on the content entity is a field, but on the config entity actually nothing is a field. We have all entity properties on there which are really just like simple plain object properties. So when you access like a property on a few which is a configuration entity, it won't be an object. It will be just whatever is in that property. So if we access the few name, it will be directly a string. Well, when you access the node title that actually is going to be a field object in particular a field item list object. So you'll have to use L value to get the string of the node title. So that really is a major difference when you work with configuration and content entities right now. Okay, let's have a look on how you could actually use then the new API to provide new entity types. And I'll really start with content entity type and focus on that mostly. And later on I have a short look at configuration entities and how those work as well. So for defining an entity type in Drupal 8, you basically just have to define a class and put an annotation on it. So that's really the basic principle of the plugin system in Drupal 8. In case you don't know, it's really simple. You just have class, put the right annotation on it, put it in the right location and the system will pick it up automatically. So it works really like that for entities as well. So if you can see here, there's a defined class for comment, just extends the base class implementing a defined interface as well. And the annotation on it actually specifies all that information that in Drupal 7 was part of hook entity info. So that's all now in one central place and as it really belongs together. And as in Drupal 7, the information that you specify is quite similar. Like you have to specify the machine name, the label, stuff like that. And then more important are all the different controllers which are all the classes which stick care of how your entity behaves in the system, what you'll have a closer look at those now. Then when you define the entity class, what you also need to define is the fields which are on your entity. For that there's an aesthetic function which is called base field definitions. You just implement it and basically return an array of field definitions that are on your entity. So for example, in comment entity, it comes, of course, where fields like comment ID, UID, but then also has parent comment ID, comment subject, all those would be examples of the comment base fields. So you implement the method base field definitions, create field definitions for all of the fields and return it. For creating field definitions, you can just use the class field definition, create a new instance past the field type and then you have methods to define all the further details of a field definition. Usually you want to define a label, but of course the stuff like field type dependent settings. So for entity reference, you also have to specify like the target type setting which defines what entity type is being referenced. Then what's really a nice feature and I really like about the new API and the blade, is that we now are able to use widgets and formators on base fields as well. So that means like this is the definition for widgets and formators of the node title. So the node title is now actually rendered with a field formata and is being edited with a field widget. You can configure which format and widget to use with the sets display options method, you just pass the ID of the widget or formator at the type option and you can specify like the weight and the additional settings there as well. And then very important also is the sets display configurable method which allows you to specify whether the widget or a formator is actually configurable for the user in the UI. So if you're providing an entity type and you don't want the user to be able to configure your base fields, you just don't have to enable that but you still can make use of all the widgets and the formators that are already in the system. But if you want the configurability, you can easily just turn it on as well and it will just work as for configurable fields. Then speaking of storage, for implementing the storage of your entity type, you just have to specify the class which is content entity database storage which is a class you can just use and it will provide you with full grad storage for your entity type. And then you always just have to implement the hook schema which means you have to define all the information that's in your base fields again. So we thought we can do better. So since Sunday, we actually don't have to implement hook schema anymore and it will generate it automatically for you based on the field definitions. So you really have just to take, oh thanks. So really you just have to take care of your field definitions, make sure they are well defined. Like you can also define whether the fields are revisionable or translatable and the system will generate the right tables for you and will take care of doing that. Then sometimes it's not enough to trust the entity storage and entity query to work with entity type but you need some additional queries like talking directly to the database. So in Drupal 8, you really should encapsulate all that direct access to the database in the storage layer. So if you need that, just use a new method on your entity storage class, add it to its interface, like here it's defined in common storage interface. So everyone who would like to swap out the storage for entity types easily sees where you're talking to the storage and can provide fitting replacement implementation. And then to work with entity storage, as we have seen before, you can just use the manager. I could get storage on it and use whatever storage method you want to use, like save an entity loaded. Then any storage dependent logic, it shouldn't go into the entity storage, of course. So for that, we have provided utility methods on the entity class, which get invoked by the storage. So like all the hooks, you know, like a pre-save hook, also we have post-save for incident update. All those hooks have equivalents in the entity class. So there's a method on it, which is actually called before the hooks, and allows the entity type to implement any storage in the dependent logic. Then for rendering and a content entity, you actually can just use the view builder. You just specify the class in the entity annotation and they're actually good to go. It will just render all the fields with the formatters that are defined for the fields. Then for forms, it actually works really similar. There's entity form class, which will by default use all formulas. But in addition to that, also entity operation forms, like the form to delete the form, are also handled by entity forms, and you can easily customize them as well. Of course, you just extend the base class and you can override methods, like for overriding the question of the deletion form. And then to access the form, you have to do that via an entity form builder service, which then has get form method and it will get the entity form for you. So that's actually looking rather complex, but the good thing is that usually you won't have to do that, because in the routing system, there's already a special key called entity form, which you just specify which form and you basically just put in the defined entity form for you so you don't really have to do the glue code either. You just specify the form and you are out. Then for access control, there's also a separate access controller, which you usually want to extend to specify your custom entity access control functionality. You just extend the method and implement the student method for defining the default access of your entity type. It's really straightforward. And then of course to check access on any entity type, you can just get the access controller from the entity manager and call the access method on it. Then finally, there's something called entity list that is actually mostly used by configuration entities as it's useful for providing like an overview screen and administration UI, so you have a list of all the entities in your systems. And yeah, the entity list controller comes with just a usual predefined list, which of course you can modify by extending the entity list controller and overriding some methods. For content entities, actually, fuse is used all over core, so that's why entity lists are mostly used for configuration entities. But I guess you've seen there's really a pattern behind all those entity controllers and how you can use that. So it's really about providing reusable functionality based up my well-defined interface so everyone can easily make use of the functionality. But also, the entity controllers really allow you to easily customize certain aspects of your entity type so you can always just easily extend the provided controller, override some methods, so it's really set pattern for that. And finally, entity controllers can easily be provided by content modules, so they can provide new sorts of new flavors of entity controllers, so they can allow other entity types to easily customize the behavior of a content module. So it's really a neat and easy way for modules to allow for easy per entity type customization. So if you know controllers like from the MVC pattern, you might be actually a little bit confused about the term entity controller because it's totally not a controller in the MVC pattern. So as Drupal 8 also uses the term controller that way now, it's actually a little bit confusing to have entity controllers and controllers in the MVC pattern sense. So we actually think about renaming controllers to handlers to avoid any terminology confusing. But that doesn't really impact on how you work with them anyway. But there's even another pattern, so few really introduce a new way to provide you with reusable behavior along with storage for entity types. And there are multiple examples for that in core already, like we have got now a new UUID field. So all the content entities have few UIDs, in Drupal core, and it's just a field that's defined for each of those. And the field actually encapsulates all the behavior that's really specific to the UUID field, which mostly means like, okay, when entity is created, a new UUID will be generated for your entity, and it also comes with a meaningful validation for your UUID. Actually, that's an example of a field type which is not exposed to the user interface. So when the user goes to the managed field screen and adds some fields, the UUID field won't pop up. So you can configure that by field type. Then another example would be the language field, which really symbolizes just use for the entity language and comes with a meaningful default value behavior. Then there's the path field, which is used for the path aliases of nodes or terms. And it's interesting from that perspective as it also implements methods that react on entity insert, update or deletion to control the path aliases that get stored in the pack. So it really is a nice way to encapsulate that logic as well. You don't have to implement the hooks in the module, but can also move that logic in directly in your field type. And it really helps to encapsulate the functionality. Then, yeah, of course, we have more of those, like graded and changed fields are good examples which come with meaningful default value behavior as well. Yeah. Then, as mentioned, we also have your entity validation API. Entity validation actually really is important because of the Dressful web service that's to relate ships with. Because of the web service, you really want the web service to run all the validation that it's needed for your entity type. So to be sure that all the data is actually valid, you don't really want it to skip it. So we cannot do all the validation in the form layer as it was done in part seven. So we decided to move all the validation logic to a separate entity validation API which is totally decoupled from the form layer and can be used without forms as well. And so we are actually using another symphony component for that. There's a symphony validator component which works based on a set of constraint plugins which means there are a lot of useful constraints like for checking the length of something, the range and really, there are a bunch of them and you can just reuse them to define your validation constraints of a field. And it's actually working like that that there's a method set property constraints on the field definition which allows you to easily set constraints on all the individual field item properties. And as well there are methods like to set constraint on the whole field as well. And you specify just the ID of the constraint. So in this case it's a custom user mail unique constraint and you also can specify some constraint options. In that case the constraint doesn't take any options. So the user mail constraint is just a custom implementation that makes sure that the mail address people add are actually unique. And what's really nice about the constraints is also that field types can define default constraints like an email field comes just with a constraint to validate that what the input is an email address by default. And then to making use of the API there's a validate method on an entity which you can call and it will validate the whole entity for you and give you back a list of validation violations and to see where entity validation passed you actually can just check the count of the violations as seen here. So if the count is greater than zero obviously there wasn't a violation and validation failed and if it equals zero the validation passed. Then when you have a violation the violation actually represented as object as well and it gives you easy access to the error message which is already properly translated everything it's ready for you to use. And it also has a reference on the actual property that failed validation so in that example it's actually the default format of a text field. Then the mapping back of the violation errors actually is taking over by the widgets. So when you're implementing that just make sure that for field you have a widget in place and it will automatically map back the violations to form errors as well. Then of course you can define your constraint plugins. It's again working based on the plugin system usually define a class and define location put an annotation on it it's all following the same pattern. Actually the constraint class here is used for the constraint settings and the messages. So this one contains the default messages and then the actual validation is done by another class the so-called constraint validator which is just specified here but a validated by class and by default just uses the naming pattern like for range it's a range validator so you don't have to override it. Yeah entity query also got improved a lot for Drupal 8. I really just took the most important things. So first off it's really abstracted now it's easy for each entity storage to provide each own entity query component as well. So like MongoDB can provide a new entity storage layer as well a new query class which automatically supports all the entities that are stored with its storage layer. So that's something very, very important and very useful to work with. And as everything now is a field you don't have to specify like whether you are querying a property or a condition anymore whether you're querying a property or a field anymore there's just a general condition method on it and you can use it the same way really like DPD and G works in Drupal 7 so it's more close to that now. But when you execute it you always get back the area of entity at these and you can easily load the entities from there. Yeah, so it works independently of the storage and it's defined actually when entity query service that gets reused and better storage. So what's really nice about it is that it now also has language support which means you can easily query entity conflations right it has relationship support but that's of course only possible if your entity types are based on the same storage engine like you can only use relations when both entity types are stored in SQL and the entity query driver supports it. Then there's also aggregation support like for counts and everything. Okay, let's have a short look at configuration entities I talked mostly about content entities now. As mentioned it's really based on the same API so the base pattern is the same you define an entity class but we have a different base class you can use for config entities which come with meaningful default behavior for them. And then you put also the annotation on your entity class and have some different definitions like in particular you have to define like a config prefix which is the prefix for the configuration management system to store the content of the entity in a configuration management file. And that actually is going to be taken over by the provided storage component you don't have to customize that. Yeah, so when you're providing a configuration entity what you usually do to define what's stored for your configuration entity is instead of defining base fields you just define public properties like public object properties on your entity class and all of those properties are be default picked up by the configuration system and stored. So actually that is what will be returned in the two array method and that is what's being picked up. So if you want to customize what's going to be stored for a configuration entity you can override the two array method and add customized whatever data is returned by the method will be stored. Then finally when you're providing configuration entity you really should provide a configuration schema as well. It's not technically required for the entity to work but it's required for the translation system to work with your configuration entity. So it's actually goes in a separate file and I won't go into the details here as it's not really related to the entity API but you basically just define a schema for all of the entity properties that you are going to store in your configuration file. Question is whether that means whether the config is generated on medically. So you have to define the schema for the configuration of your configuration entity but then of course for each instance for each entity that you're going to save that the config file is generated and saved for you. I hope that answers the question. Then I also want to shortly mention the type data API which really is an underlying API of all the entity field API. You don't really have to know about it directly for being able to work with the entity API but it's really built deeply into the system and this API is really an API about metadata and being able to leverage the metadata. So it allows you to describe the data using type data definitions or like also like field definitions which are really similar to that and the API works on based on extendable list of data types which are redefined in Drupal Core like have data types for the primitive data types like string, integer, or float but of course it also covers or Drupal specific data types like entities, nodes, also field items of a certain field type. And it really helps the modules like the REST module for providing web servers in Drupal 8 Core and counter modules are going to use it a lot like rules or C tools, Drupal 8 variant or search API is already going to build up in that and hopefully we also will be able to have tokens generated based on the type data API. So you see we are almost there we have really achieved a lot I think for the Drupal 8 entity API but as always we are not totally there it's not everything finished so we are still working on some items and trying to get ready for the beta. Mostly our focus right now is actually on completing the schema generation and that it also it's possible to handle changes to the entity schema. So right now it's not possible that's really one of the huge beta blockers we are working on a lot this week and this time. And what's really great about that is also I will ease reusing entity field search for modules because that means when you have a module and you want to store some data for the entity you don't have to create your database table for that anymore you can just use the system implement the hook and add a field to it and the entity storage will be able to take care of the storage for your field for you and you can just reuse that. And finally we are also working on entity cache support and getting that in actually already pretty ready and we are close to having that committed as well and entity render caching actually is already done so that's a really nice performance improvement as well. Yeah so if you're interested in doing that you're really welcome to get involved. We have a major issue which is called complete the entity field API which should give you an overview of all the issues being worked on and we have also weekly ISE meetings in a Drupal-entity which happens each Thursday at six o'clock central European time that's seven hours from this time zone. Yeah and of course we have sprints here on Drupal-CAN and so if you're interested in getting involved or getting involved with Drupal coding in general not necessarily just entity but I really come to the sprints they happen on a Friday, there are a lot of tasks for every skill set, there are mentors available that help new contributors and there is even a workshop to help you to set up with the community tools. Okay so also before we move on to the questions I want to use the opportunity and highlight some of my other pet board projects as mentioned I'm also a maintainer of the rules module and right now we are actually starting an initiative to get the rules module ported to Drupal-8 and we have started a Drupal funders campaign where you try to gather funds so we can move on with the port of the module faster so we can also use work hours and because it really wants to get the module ported as soon as possible and don't postpone the release to someone really late and I don't think that anyone wants to happen that. So if you like rules please visit drupal.org and support us so okay that's it, any questions? Maybe come over to the microphone and then speak into that please, so questions. Yeah so you mentioned a little bit about entity querying like the way entity field query works now in Drupal-7. Does that, does views use that by default because now I'm trying to remote entity stuff and entity views, any field query views and it's tricky to wire all that together. So unfortunately views is not using entity query yet so there's been some discussion about it so it's using it still its own query system but I really hope that there will also be a counter efforts that will provide a query plugin that's based up on entity query for views. It's doable but it's not done in Drupal-8 core. Thanks a lot. Thanks Pago, everyone who's worked on this, this is amazing. My question is about the piece that you were talking about you're trying to get the schema automatically generated based upon the storage definitions and you're having problems with migrations like if you generated that schema and then you wanted to add another field. You don't want to throw out what you did. You wanna be able to just make that additional field added or maybe the type of the field changed or something like that. Where are you currently with that work? Yeah so as mentioned that's the handle of changing to the entity schema and that's one of the issues we are still working on. So that's not there in Drupal-8 at all right now so right now you can just provide field definitions and that's it, you cannot change it. But we are working on it and we will introduce a way for you to add new fields but you will be limited in what changes you will be able to do like as it's already the case for configurable fields they don't allow you to change like the field type of an existing field because there's no upgrade for your storage. We will also limit like what you will be able to do with changes. So we should be prepared to do it right the first time or throw it out? Well you can always just add another field and migrate your data yourself but there will be no fancy data migration in the back for just when you change field. So if you make a mistake catch it early before all the data is flooded in. Yeah, that's a good idea to do. Got it. Yeah, that's something there. Just an addition to Faco's answer. We are not allowing these kind of changes in core because it would mean a lot of complexity introducing a lot of complexity but actually it would be possible to provide in contrib an alternative handler for these changes that could leverage the migrate API we are introducing in Drupal core so that actually could support the wider range of changes and providing data migration while doing that. So actually we could be able to address the concerns that he was pointing out. Thanks, more questions. So one of the things that we've noticed building with these seven and all previous versions of Drupal is that the user system and registration is one of the most magic and sort of hardwired part of everything we've gotten used to. And a lot of our challenges come around registration and hiding user names or allowing for non unique email addresses and things like that. And I may be missing the obvious but it seems as if everything is now a first class field on all entity types that stuff like overriding the requirement that email addresses be unique is now possible. Is that, does that seem to be the case? Is there some way provided for us to say no you don't have to have a unique email address? Actually that's not something that the conversion does take care of it. Like it makes sure that it's defined like that and it's available to everyone that you know it's unique but it's not making it magically work that you change the field definition and everything takes care of the change as well. So it's always like when you alter something you have to know what you're altering what's actually working or not. So as Dries touched on in the Q and A this is a pretty radical evolution and it's gonna be pretty tricky for many developers to learn all these changes and make these changes in how we do our work. Some of that is a bit, some of that challenge is a bit offset in that now that because everything is object oriented it's a lot easier to sort of discover how the pieces interact and work together as long as the IDE can sort of automatically discover these relationships and everything like that. But naturally there is sort of a limit in how far an IDE can discover it. For example the IDE isn't gonna know what fields are on your node. But can you maybe speak to some of the things that are in place to make that sort of discoverability happen and how we can leverage that? Yeah we really tried to have the discoverability built in as far as possible but as mentioned of course for dynamic stuff like the fields it's not possible out of the box but I think what we could do here is really work with the IDs to have integrated IDE support like have special plugins that are able to pass like your configuration and based on that can give you autocomplete suggestions. I think that's actually doable for most IDs. Great presentation thank you. My question is about with these changes to configurations being introduced now how does that impact the features module and can you talk about that a little bit? Actually not too knowledgeable of the configuration system but really the configuration system is an underlying system that features module would need. So it really takes care of being able to stage of all of the configuration from a Dev site to a staging site to a live site and it's also possible to make individual modules with come a bunch of default configuration items and really feature module can work based on that and to provide all the clue to our medical to generate and maintain the modules I think. Thanks for presentation and I get question about base fields and bundle fields. So at the moment stuff like title the actual stories and properties so actually moving it into a base field does it mean that actually each field gonna have its own table or does it mean that actually we will be able to choose if we can wanna store it as a database column or as a separate table? So configurable fields are stored as in triple seven so they're using basically the same approach of one table per field but base fields still use an as efficient table layout as possible so we generate it depending on the revision of the table and trance available flat what means like for notes there's a table with the data of all the base fields in it basically. So all of the box that means for each configurable field added it will be at another table but what it also means is that more easily you could just convert a configurable field like to do a base field and have better improved storage while all the API that's working with that field is actually the same so the rest of the system actually won't care whether it's a configurable field or what's the base field and how the storage treats it so you really have everything in your hands to improve the storage and easily make a more efficient storage without having anything of the rest of the system notice. So does it mean that the new notes in triple eight are gonna have title in a separate table? They could but right now the title is stored as 2.7 like it's only one table. All right, thanks. So now that properties are fields does that mean that I can like put an image above my title without like hacking all the preprocess? Good question. I don't know, you would have to try I hope so. Cool, thank you.