 My name is Sasha Rosenbacher. This is Wolfgang Ziegler. You might know me under my nickname Berdir and this is Fago. We are going to talk about the state of the new entity API and type data. We also use a lot the term entity and G a lot, but that's basically for entity next generation and but it's more a temporary thing while we are moving to the new API. So that has just been a temporary class name and it turned out to be, yeah, the term we used to call that thing internally, but it's not an official name of the API or something. Exactly. Better? Okay, sorry. I guess I'm too big. So our agenda today, I have a short overview what the API is about. Then we show what the current API can do and how it works. What the current status is and some problems that we have with this new API. We had a lot of discussions on Sunday and yesterday about these problems and how we can solve them. So we have a list of proposals and ideas, what you can do to improve developer experience and performance and so on. More on that later. So the basic idea is to have an object-oriented API to access stuff on an entity. So unlike in Drupal 7 where you have properties which are to base stuff like the user node title and the outer user ID and created timestamp, we call everything a field node and there is the difference is there are non-configurable fields which are defined in code and are stored in the predefined existing tables. For example, the node table and node revision table and there are configurable fields which are filled with a field module and these are stored in a talk table, the field data tables. So the storage is basically staying at the disk. There's going to be new stuff, but that's still the basic separation. But everything is now a field and the idea is that everything is accessed the same way and has the same capabilities. So what was a property in Drupal 7 is now a field as well. It's not necessarily a configurable field, what would be a field API field, but it's also a field. Exactly, so the node title is not a configurable field that you could remove for something, but you can translate it or you will be able to translate it when the patch is landing that is making it translatable, which should happen very soon. We're going to see examples and how it looks soon. So the basic features of the new API are translation that every field is translatable and there are ways to access translations, add translations and see in which language an entity is translated. The validation API, there is an access API which allows to check in a generic way for every entity on the system, if you can view it or edit it or delete it and so on. And what's important is that there is metadata and introspection, so you can, if you get any entity, you can find out if it has a certain fields or a field named a certain way and if it exists what kind of settings it has and so on. There are also so-called computed fields. We'll see more about that. So some very basic examples of the API. We don't expose directly the field values as this long erase anymore where you have to specify the language code and the delta and so on, but by default we directly allow you to access the first values, so if you have an entity and the field, that's a user reference. You can directly access the field and entity on it, which is a code, so-called computed fields. We'll see how that is defined later on, which allows you to access the referenced user and fields on that user at the same time on the same line. You can also change values and properties will reflect the updates. So for example, if you change the target ID of such a user in reference, the corresponding computed entity will be updated and we'll be able to access the name, for example, of that user. So the node title is now a class that implements the field interface and then there is the delta, so a field consists of field items and a field item implements the field item interface. There are currently discussions going on. We'll see more about it later if right now all fields, even the title and the status, have fixed structure, so they have field and the field item, but for these base fields, it probably doesn't make sense, so we'll have a proposal later on if you need that, if you want that, and how we can avoid it. So the idea behind that was that we have a common structure for every field so that you can rely on that and you don't have to check on whether a field node has multiple values or not. So that's how field API works as of now as well. But it also puts quite some additional stuff in simple things like a node title or node status that doesn't have multiple values. So, yeah, we are thinking about improving that, but more later. Yes, and below a field item then consists of so-called primitives, which are basically strings and numbers and boolean values and so on, and they can also be, as you have seen before, they can be computed and there are two ways to access it. You can call get on it and the value and that will return an object again that implements right now the typed data interface, and then you can call getValue on it to get the actual value or you can rely on the magic methods and just access it as a property on that class and it will go through magic methods and do the same as above and call getValue and then getValue. That's just a shortcut. How do you access it? The same way the title and delta is also accessed through magic methods and array access and that is one of the performance problems that we have and we have a proposal and idea how it could be changed and we'll need to see if it's still possible and if it makes sense to do so. So I have mentioned that typed data thing and what it's about is a way to express metadata in Drupal, so it allows you to define your structure, define what your entity consists of and then someone else can, for example, build the user interface for it. So if you have a custom entity and then the rules module can take that definition and display a form that's dynamically built based on your entity and maybe configurable fields on it and yes, so that is defined view, defined based on configuration and can be accessed on runtime at any time on any level. So if you have a field, you can access its definition, if you have an entity, you can do so as well. The idea is to have reusable interfaces for these structures. We have, I've mentioned typed data interface, which is the basic interface for all these different structures. I've already shortly talked about use cases, so the obvious one that we are right now using is the entity field API. That's what we are talking about. Other examples are blocks and conditions. So for example, that the block that displays information about a node outer can define that it needs a node or a user as context, as input and that can be defined and some system outside of it can decide what information do I have at my hand and how do I get the user from a node. And another example would be the token module, the token system, which has its own system for this finding metadata and how it's connected. It's not yet relying on typed data, but I hope it will be at some point. And I guess most of you know the C-tools context system or the rules data entity properties from Drupal 7 and the idea is to have a unified system of that so that we don't have to maintain and use three different systems anymore. Yes, in Drupal 7 the C-tools world with C-tools context is really just different implementation for the same as what the entity API model with the entity property infosystem does and rules mix use of. So we have that in Drupal 7, which are two systems that do the same and we also have the token system, which is also related because it also exposes related metadata. And with Drupal 8 we really try to have a common API in quality we can use instead. I mentioned the reusable interfaces. Here's a bit more information about those. So there's the basic typed data interface that's every type data object implements this. It allows you to get the value of it, the definition and information like that, set the value and so on. There is the complex data interface. It's basically a type data that has properties that has children's or more type data within it. For example, a field item has the primitive values, a text item has the value and the format and an entity reference has the idea of the target and the computed entity based on it. And there's the list interface, which as the name says, is a list of data items. So the field implements that interface and has a list of field items. And there are specialized interfaces. There is a translatable interface, which says that something can have translations and is translatable. There is the accessible interface, which allows you to check if something has, a user has view or edit or delete access on it. That's implemented both the entities and the fields. So you can check on any level if a user is allowed to see that field or that entity. Yeah. And so for that, the type data API works based on the two by eight plugin system as well. It has the code data type plugins. So you core comes with a set of basic plugins that you need there, but it's extensible by contract. And it starts with the set of well defined primitives, which you cannot extend. So it makes sure that there's a list of predefined primitives that's not extendable so that you can rely on that list of primitives in your models. And yeah, some examples of that base string in digital flow to your eyes. And then in addition to that, we have a field item types in core. So each field type needs a field item type right now, which right now two different things, but we are working on unifying that as well. So, but that's, yeah, another issue more than later. And some examples would be a string item or also a new your ID item because your idea item. So we have a UAD is in core. We have a UAD field, but it's not a configurable field. It's just an entity field. So we have a class which defines the data type for that. Actually, I think that's not yet in head, but there's a patch for that. What are the entity reference item, which is for the field item of an entity reference field. Then we have the field class, which actually is just the list variant of the field items. So if you have multiple of those, they get wiped in the list class. And all of those implement the type data interface, as all of those are type data. But for example, the list interface is only implemented by the field class. And the complex data interface would be implemented then by string items or UAD items as those contain named properties. So this would be an example of a typed data definition. But this is just an array that you use to describe any data value. So in this, this example actually describes the comment new field. So if you want to comment, you can check whether comment is new. In Drupal 7, I think that was just done on demand with some on-demand code. In Drupal 8, we have registered as an entity field that's a so-called computed field. What means it's a field that is not stored in the database, but gets its value computed on the fly. So when you access it, it invokes the method of the class and commutes the value. So when you look at the type data definition, we have mostly have the data type, which kind of the core of the definition. But you also have additional stuff in it like the label and the description, the computed flag, which is optional. And you can also specify a class which will be used for the implementation of the field. The class flag is also optional because the type already refers to the typed data plugin. And by default, those class will be used. And if you define the class flag, you can override the class that's used that way. And there's also some additional keys that are not in that example. But yeah, it's not that important. I think you get the idea with that. So this is actually the class that is referred by the implementation. It's the class which calculates the value on the fly. So when you access the value internally, it calls get value. And if the value is not already statically cached, it just computes the value on the fly and then turns it back to you. So that's it. Okay, so let's have a look on how the typed data API and the new entity API relates to each other. So as we mentioned previously, the complex data interface is for everything that contains a set of named properties. And when we look at an entity that also matches that description, it's just that we call the properties fields, but also we have names for them. So it's a data structure that contains other properties. So an entity is an instance of a complex data interface and is that way also accessible by that generic interface. And as an entity is translatable, it also implements the translatable interface. Then we have a look at the field instance at the node title. It's an instance of the list interface, but also lists an instance of the type data interface. And then the field item. So like the the second title, but we don't exist. So that's the first title is an instance of the complex data interface also, as it's a field item. So it contains potentially multiple values of what that example just contains one, which is identified with the key value as well. And when you use the data method to get that, you actually get back the type data object as well instead of the plane value. And then you can use that API also to the introspect the entity and what's in entity or in a field. So you can use get type methods or get definition method to look up the definition. And there are also methods to get the properties that are inside some complex data or to get the definitions of those properties up front. Then the type data API also includes validation. So it makes use of the symphony validator and integrates that with the type data. So that works by a circuit constraints symphony validator has constrained classes, which just defined the validation logic. So for example, if you want to validate an integer, you can use the range constraint and specify the configuration of the minimum and maximum value of the integer. And the range constraint has all the validation logic needed to validate the integer. So there's already a set of predefined constraint classes and symphony validator, what we also reuse and integrate into Drupal also via the plugin system. So we discover the constraints via the plugin system. And you can add your own constraints to the end your own validation logic. So the validation is really built into the type data API and will be leveraged by the entity API as well. But it's still working for us to really leverage it in the entity API also. So this is an example on how you actually could use it to validate something. So when you have a type data object, like a field is, you can just call validator net, and it will use the configured constraint and validates value against the constraint. Then you can just check that the violations you get back, which actually is a class which implements the violation list interface, I think, you can just check the continent. So whether there's a validation in it or not, and if there's no validation, obviously validation passed. And if the violation fails, you can get the translated message by just by calling it, and you can get the message on it. Yeah, and then once we have that validation that is decoupled from forms, we can make map it back to form errors. So the idea behind that is that entity validation becomes totally decoupled from forms. So it's reusable. For example, when you use it in a web service, we really need to be able to validate the entity independently of a form submission. So it can fire up symphony validation. But when you use the form, it will fire up the same validation in the back, and then map just the violation errors back to form errors. As we are currently in the conversion from the existing entity API to the new API, we need to implement the backward compatibility mode to make stuff like the field API work, which works with some entities that are now converted and some that are not. So we have the backward compatibility mode to allow the field API to work with all entities as like they won't be converted. So you can just access the title by node error title as previously. Or you can also access the node body as previously with the field API way of doing it with recognition of specified zero and the value. This backward compatibility mode is right now in use for nodes and also for other already converted entity types when they are then used by the field API, which is obviously slow because it adds another layer on top of it. And it also requires some hex and a new entity API like to make the magic getter work by back to the field API. So we need to do that. So we need to do the conversion first. So let's see what's the status of that. So as mentioned, the conversion is currently in progress. We have comments fully converted and as mentioned in the previous slide, node has been half converted because it's still using the PC mode, the backward compatibility mode. And we have available entities left like user contact message and test entity. But actually we have made good progress on those as well. Yes, so users have a patch that almost complete and the same for contact message, which are actually now an entity which is fieldable, which means that you can build contact messages and send them to you. And I'm also working on the files. And there is some, the files aren't fieldable, so they are not blocking the field API progress, but still needs to happen to complete it. And the user and contact message both have a single issue that's blocking them, which is at the PC. And I hope it's going to be committed soon with the core maintainer in this room. Yeah, and then regarding the config entities, we have not started converting those yet. There's actually not fully agreement on how that should work out yet, but there's actually a discussion scheduled on Friday on it, so it needs some work to actually do what we will discuss on Friday. For our translation, actually we have entity translation module in core. So translation works basically for entities, but we don't have all entity base fields, which were previously properties converted yet. So converting all those base fields to be translatable means that we have to adjust the storage of them so that they actually can store translateable values. It's not only about making the API to allow to access translatable values. So we have to actually work on the storage part. And red notice, work on node is, yeah, it's work in progress, but there's already a pretty good patch. Then to validation, as we have seen previously, what I've shown you works, it's there, but it's not really used in core at all. So it kind of was postponed on moving the entity objects to fully implemented type data objects also because then they would automatically receive the full validation. So what to do here is to actually start converting all the field validation logic and widgets to the new API. So we need to move the existing logic to constraints and the widgets to actually map the symphony variation errors back to the form instead of the previous one. And then we need to adjust the entity from controllers to take validation account for the base fields, which do not have widgets yet. And we need to convert also the entity base fields to actually use the new validation also. So that's really just converting all the existing logic over. The API is in place, but still it's, of course, quite some work to convert everything. Then in regard to the field API, the entity field API kind of overlaps in parts of the existing field API. And we are working to unifying things that make sense so that the field API just adds the configuration part on top of it. So it's really working progress as well. So my shirt is actually working on finishing the field types as data plugins. So link the issue if you're interested in looking into that. So it's something we'll definitely work on this week and try to get it done as soon as possible. Then there's an issue to make formators and widgets to work on all fields. That means you would be able to also use formators and widgets with base fields. What is also very important for the edit module so you can just make use of the same APIs to edit the node title, for example. And then there's the task to switch to a unified storage, what means to move over the field based storage to the entity storage controller as well. There's an issue also for that, which Jax is working on. And I think we have a slide for that. Yes. So the mixed entity and field storage, as we have it in Drupal 7, it did not really work out because when you have an entity and you store the fields in MongoDB and the properties are stored in SQL querying that becomes really hard. So there was never a solution for that and no one really cared about implementing that because it's really, really complex. So as no one is interested in doing that, what we are going to do is that we unify and simplify the storage. We move it to everything to the entity storage controller so that the entity storage controller becomes the single class that's responsible for storing everything of an entity. So field able entity types then actually become so-called extensible entity types. Well, whatever we decide to call it, we are not settled on the term at all. But it's not the idea that counts. Obviously, field able, the term doesn't make much sense anymore than every entity has fields even if you cannot add configurable fields. So we need to find a new term for that because we still have the distinction between an entity type that you can extend with custom fields that you add and an entity type that doesn't support that. And what this also opens is that you can reuse the field storage mechanism for storing module data because you can just use the entity storage and tell them to create storage for a new field and you can just use that for storing your data without getting automatic integration with the field API, with widgets and formulas and stuff like that. So you can code that you also can your module as it suits your module and just reuse the storage part if you want. What's an important side effect of this is that it's going to be even more important in Drupalite to use the entity field query, which has been improved a lot. And so because everything, so if a node is going to be stored in MongoDB, everything is going to be there, so you're not going to be able to do a query, direct query on the database to check for published nodes. You will need to use MongoDB as the entity field query for this. And also entity query is much more important because of the multi-lingual support for everything. So as soon as something is translatable, you really should use it so that you can easily decide which language to query. Okay, so let's get to the problems. As Bari has mentioned, we had quite some discussions on that recently. And every one issue people had with the existing code is that the type data interfaces, which all of those classes implement, have some quite generic methods and names in it, but then in the context of specific objects, it's like when you put it on the entity object and on a field, not necessarily make a lot of sense and then end up to be confusing. So right now we would have, let's say, entity get property definitions because to type data, everything on an entity is a property, but entities will now call it feeds. So that's quite confusing then. Then we have a method on a field item, get value, which gets you the plane value of the field item, which is actually something different in comparing to using the gather to get the value property of it, which gets you the type data object of the value column. But semantically, yeah, it's quite the same. So that's confusing as well. Then another problem right now is that we cannot really get metadata for stuff you cannot instantiate. So when you think of, because we are using the same classes for that right now, when you want to get the metadata of something, you can just instantiate the type data plugin and before the value and use get property definitions and something to read the metadata. But what are then the fields on a node when you cannot instantiate a node because you can't instantiate a node if you don't know the bundle of it. It requires the bundle to be instantiated. And if you don't know the bundles, you don't know the node type, you cannot instantiate it. So that would be no way to get the fields of a node. So that's us. We need to solve that. And then performance has been a problem as well. We did quite some work on it and improved it. But still we have multiple magic methods when we access something. So when you call, for example, given node body value, it internally invokes the magic gathers and it boils down to the second line of code to node magic get body, then offset get for reaccess to get the first field item. And then it has a magic again to get the value. Initially we had even another layer, but we reduced it to that. But still it's quite some magic to get invoked. And then another problem we face is complexity. While the API gets nicer to use and it looks much simpler than previously, the complexity is hidden away. So internally there's quite some stuff going on just when you access the value of a feed. So we have that great simple access, but at the cost of some high internal complexity. That's not really something that we kind of change right now, but it's not not nice. Okay, so let's get some to some actual pro proposals to deal with the problems and improve that. So one of the big issues was the problem of the generic methods on everything. And to get a baby without that, the idea is to move more to interfaces. So instead of calling get type or get definition and objects to get the metadata and then check what type it is and do something, we want to rely on interfaces for that. Because it's a language-level feature, what we really can embrace in that situation. I think we really should do that. So instead of the first line, instead of calling entity get type, which actually won't be the entity type, but the type data type of the entity. And check that, you can just do entity instance of node interface to check whether it's a node and another and another in a logously to the to check it from the integer, because the integer is also a class, which is a type data class, which wraps the integer value, and you can just call instance of integer interface to check whether it's an integer or not. And then when we have that, it actually allows us to remove the type data interface, because we don't need it anymore. Do we access the types and the definitions? So we can remove that interface and we can remove the generic methods from objects like from the entity or from the field and replace them with methods that make sense in the individual context. So on the entity, we can just delete get type, we don't need it there, and we can replace get property definitions by get field definitions, what makes more sense in that context. Then another proposal and another thing that we discussed during the last two days was moving definition arrays to methods and interfaces. So right now the definition, like the field definition is an array, and we could move it to a class that brings us some better documented definitions and some better developer experience. Now for it, all of them might have performance implications and might make it a little bit more inconsistent with metadata that you have elsewhere like the plugin definitions, which are usually array based. So I'm not totally sure that we should do that, but definitely we need more discussion. Yes, that's something that we need to discuss during this week. It was an idea that came up on the weekend and we also not sure there's different versions and how to do it. We could still define the definitions as arrays, but allow to access defined methods and how to access it. So for example, you could just call is translatable on something instead of having to call get definitions, which turns an array that is a translatable key. So we still need to discuss this. Okay, next, when we actually change the interfaces, like removing get property definitions, then the question comes up, how do you check for the fields on a load then? And I think for that, it makes sense to have get field definitions just in the entity manager. And actually there's already a patch in the queue to do it like that. So when you don't have the node at hand, and you cannot instantiate the node, you can just ask the entity manager and get the field definitions for of a node. But then we even have to answer that kind of question on a more generic level for use cases like the rules has or the block interfaces have with contexts. So generically speaking, what are the fields on any contextually data? So how can you derive that with the system? So as of now, you use the type data API, you take the data definition, instantiate the type data object, and then you just use the objects to check the interfaces and to call get property definitions and stuff like that on it. But as soon as we don't have the data, we can get property definitions on the object itself now. So how would it work then? And I think what you should do is something like that. We have a definition as previously, but instead of instantiating the type data object, we use the type data manager and ask it, that's something. Yeah, that's the new one. So we actually just call get property definitions on the type data manager and pass the context definition and want to get back all the definitions of the child properties of the defined data. So if you pass in the definition of a node, you would get all node fields. If you pass in the definition of a user entity, you would get the list of all the fields on a user. And for that internally to work, we kind of need to tell the system on how can it derive that. And we thought that we would just add the support for definition driver classes, like an entity property definition driver, which then is able to tell the system how to derive the property definitions from entity, or a field item property definition driver, which can do the same for a field item then. And when you specify it, it could be done in the type plugin definition. So when you add a type plugin, you just specify the driver class, which then could be even populated by default for some use cases like for field types. For others, when you just do a new data type, which is not related to any other data type, you could just specify your own. And yeah, it's mostly the problem for complex data interfaces and get property definition where we need to do that. The other use cases list interfaces, where we think we should just move to something like that in that we have just a definition of the items that are contained in a list directly in the context definition. Right now, it already looks similar to that. But as of now, we specify the definition of a list by having the type, so the type of the item directly at the main definition. So it would be type string here. And then in addition, we would have an additional key that says list is true. But it's a little bit confusing, but it ends up with a mix of the definition of the list and of the list item. And it's not really clear whether some additional stuff like the validation constraints then refers to the list as a whole or to a list item. So what we propose here is that we make actually lists explicit separate data type plugins. So we just register a list, a special list, like a list of strings is a new type. And then you can refer to that. Yes. And then as mentioned previously, to improve performance, it might make sense to avoid the unnecessary objects by not enforcing field API structures. So right now, as it is in head now, when you access the node title, it has to instantiate a field class, which is the list of node titles, and which then contains the field item, which then contains the value, the actual title. So we have two intermediate objects just for getting the node title. And while it's nice to have that unified structure, and you can rely on that structure, I think we really should move away from that because it turned out that the cost of creating that intermediate objects is right now the major slowdown of the API. And for all the base fields on an entity, like node created, not status, not title and stuff like that, most of them are actually single valued. So just by making it possible to do away with the list class, we can see one intermediate object for all of those. Yes, and the reason we haven't converted config entities yet is because third overhead is even bigger because they don't have any fields and they have a much more strict defined structure and simpler structure. So enforcing field and field item classes on them is a lot of overhead. And for them, we could even go a step further and just define that in config entity directly has strings and integers and so on on the class. So we could have a get title help method and you could also access the type data interface or the string interface string class of it through get title. And then you can still get the definitions of it and find out what the config entity consists of and expose it through rest or something like this. So with that, you can still use the metadata and you can still check what's in it, but you cannot just blindly go anywhere and rely on that. What you get from an entity is a field. And I think that's what we should do to make sure the system is this limit and efficient here. Yeah, then another proposal that we discussed during the last days was instead of using the current magic accesses, make the access more explicit and avoid the magic, which also saves some performance overhead. So as we mentioned previously, when you access node body value, it boils down to magic calls like in the line below it uses magic get to get the body field class, then it has an offset get array access code and it has another magic to get the actual value. And instead of that, we could migrate to using explicit method calls, like using just get body, then instead of using a reaccess, because with PHP 5.3, you cannot use a reaccess on the return statement of a method. We instead just add a method to access the first item or any item of a field. And then you can move on and get the value. So it won't reduce usually the number of objects or change really what it does. It's just making it explicit and avoid the magic calls. Yes, that was a suggestion that Mark Sonobau made on Sunday evening. And we're still not exactly sure about how exactly it should work. But we can first discuss it this week and we'll see. Yeah, so it obviously won't happen that we say, okay, we'll do that. And we change all over core in a few days, because that's a lot of work. But if we would decide to add the methods, we could do that before the API is frozen. And just make clear what's the major API that you should use by then, and then still have time to convert everything else to use the syntax and the way that the one that we have shown. So as you have seen, there's a lot of interesting stuff, but there's also a lot of work to do to complete it and to actually be able to rely on it and use it for all entity types, which there are. So if you want to help, talk to us here around the conference in the code lounge, and you're also going to be here on the sprints on Friday and on the weekend. And we should have issues so that you can work on tasks if you're interested. Yeah, so any feedback, any, yeah, to all the problems and proposals we had, any ideas on that? Just step up, come up in front of the mic and go ahead. Maybe something, you can see a link here. That's our tool named rocket chip that Gabor Hoitze built. And it allows us to expose the current focus issues, which we are actively working on and novice issues that you can work on if you don't, or that experience yet. I'm just wondering, will there still be one table per field in the database? Because I find that that's a real problem that a lot of big sites have. And sometimes people that want to build a new entity type, just so they don't have to have one database table per field. So that can be very expensive. So the default field as far as storage mechanisms won't change. We are just moving that over to the entity class, but it will continue to work the way it works already. But anyway, the new system will give you more flexibility. So in particular, when we really are able to complete the conversion of field API and stuff like that, you will be able to use the format as into widgets on your entity base fields as well. So it doesn't really matter to the system more than whether it's stored by a configurable field or not. So that means when you really care about the performance, instead of writing your own field SQL driver, you could also just do your own entity types and handcraft all the storage fields, everything and come up with a schema that perfectly matches your use case and still have all the widgets and formats and everything work with that. Right. And unlike Drupal 7, where even if you built a custom entity, but needed it to be translatable, for example, the title and translate it, you still have to use fields for that. And so we're back at the beginning. And in Drupal 8, the default sort of controller will support translatable and revisionable base fields. So there will be up to three tables for an entity type and you can translate your title. Hey guys, Matt 2000. I love entity module for Drupal 7. I've even contributed some patches to it. I'm really grateful for the work you guys have done on that stuff and glad to see that part of it going into Drupal 8. My question is about the typed data API. I think good frameworks and good APIs should make hard things easy. And the one hard thing that I see the typed API does solve is unifying validation for forms and services. And that's great. But I think there are easier ways to do it than what I'm seeing here. And so my question are your thoughts on that. And what are the other things that are really hard right now that the typed data API makes easier? I think what the typed data API enables you, except of validation, is getting the metadata about your data and also getting that upfront. And that really is what we are going to change now with removing the typed data interface is that not everything that is typed data really looks like typed data because there's no interface for that anymore. So that means it can implement that the API and the metadata system without putting any burden on it because you don't have the methods of it in the object anymore. You just check for an interface and you can define the metadata separately. So I think it's from that point a very good solution to have the metadata separated and in place. But it's not necessarily sitting in your objects and making it confusing and complicated anymore. Hi, I have a naive question. I think it's naive. So I just wanted to see if I followed this. Is it that so right now, if I use an entity field query, I have two different syntaxes depending on whether it's a property or a field. And so it sounded like what you're saying is those different syntax are going to are going to conflate. Is that true? Yes, entity field query API has changed and instead of entity condition and property condition and field condition, there's a single condition. And if you want, for example, to check the value of a text field, we just write condition field name dot value equals something. And you also have support for relationships. So for example, you can build an entity field query that queries for nodes of a user that has a certain name. And there's a lot of very interesting stuff in there. The entity field query and the database API are also very similar. So they both have condition and so on. So it should be a lot easier to transition from database to entity field queries in a more general way. Yes. Thanks very much. Thank you both for the presentation and for all your work on this. If you would permit me, I actually really want to make an announcement that has nothing to do with this. I just came from a conference call with FEMA, where they're talking about emergency disaster response to the tornado in Oklahoma. And there are few targeted areas where some grassroots coding efforts could really help the emergency response. So a bunch of us are getting together tonight at 730 at Coders lounge at the Double Tree Hotel to work on helping the disaster response effort to the tornado in Oklahoma. So if you want to follow a hashtag Drupal4OK or go to bit.ly slash Drupal4OK. That's where we're coordinating. Thank you. Hi, just a comment. One of my main concerns is performance. Like you guys said, I kind of like your proposal at the last bit where you have get body arrow first arrow get value. So you don't have to load like an array of data. And an extension of that, what I would like to also see is not just first, but let's say last. So if you just want to get the last value or the newest value, or even index, and then you pass in zero or one or two or three so that you just specify which, you know, item in the list that you want without necessarily loading the entire list. Yes. So the first, of course, was just an example. But for now, internally, we still load all the field data because making API that loads on demand is very hard. And it's very hard to foresee if the user will use all the data or just that single field. And so for now, it will still load all data internally. And also, if you decide to load everything on demand, it's not necessarily faster. It might be slimmer in the start button when you end up loading multiple things on demand, you are actually slower than just loading everything at once. So yeah, it's additional overhead, which might be good in some situations. In other situations, it might be actually worse. And it adds quite some complexity to everything. So it won't happen if it will be late. So but we'll see, maybe we can do that, that we want to do that sometime. But at least the method access allows you to experiment with something like that in contrast, I think. Thanks. Hi. Thank you for presentation. I have a question about validation API. How error messages are built when you fail validation and the possibility to set a custom error message per validation rule? Yeah, in the constraint class, you define the default messages that get used by the system. And the default messages then get just run by the regular triple translation system. And you can override the default message which is defined by constraint by defining that when you define the constraints for your data. So you can customize the messages of what I think it probably makes sense to go with good default messages and use those. Thank you. This is a bit of a topic, but I was curious. Since you've mentioned entity field query and MongoDB, you also mentioned that in entity field query, we will be able to use relationships. I was wondering whether in Drupal 8, we will be able to have views with MongoDB. I think you want to talk to Jixxed about this. He's probably most of the time in the Coder Lounge, but he's actively working on providing entity field query back end for views so that will be possible to build views against MongoDB. It's actually already possible in Drupal 7 because there is already a Fuse entity field query module. It has not many users, but it works specifically. Once you have MongoDB, I guess it implements entity field queries or I guess that works already in Drupal 7 also. You should try that and talk to Jixxed. Okay, I guess that's it. Thank you. Come to the code sprint and help out.