Yeah. But it also has the mapper registry mapped on it, which is interesting. It has some of its table metadata has not just the table name, but all the calls of information as well. It's interesting, it does have the same type declaration that I was trying to impose upon the traditional SQLAlchemy models. Yeah. That's one form of the data class model. If you scroll down the more inline, embedded one is there. Let me see if that's what it is. Yeah, that's the one that's even crazier, which the data class fields. So you're probably a data class as far as what your IDE sees. But then you have the SQL and the mapping stuff inside. So all of this is, well, it'll time will tell which approach becomes popular one. Yeah. Or people just use SQL model because the people that like data classes are tend to be using SQL novel at pediatric anyway. Maybe they'll just be there. I don't really know. I'm gonna talk to Sebastian Ramirez. Maybe in December or January about SQL model. Google model is interesting because it basically takes identic models and SQLAlchemy and merges them together. And Sebastian has a good feel for what a nice API looks like. So I'm optimistic for this. I haven't done anything with it, but it does look pretty neat. What he had to do was he had to modify identic space class. Because when I first looks, the man may be in this past year, about SQLAlchemy without having two separate models. I was like, okay, this bas class has got a whole thing. A lot of things going on that don't work with python descriptors. So we'd have to change. And I think Sebastian did that basically went in and changed how the network so that it's compatible in more power to them. Too. Awesome. Yeah. I have enough to work on. This is like too much for me to also work on dancing with someone else. Yeah, absolutely. Absolutely. One more philosophy thing that is not it is the one. One more philosophy thing that I want to ask about or let you just speak to because this is a key element of how SQLAlchemy works. There's other worms that work this way. And then there's also this one, I think it's called Django. People might have used a Django or before. That one is more of a traditional Ruby on Rails active record, where I have a thing, and I call save on it. Sure. You went with a thing called unit of work, which is a little more transactional, like I'm going to do a bunch of stuff and then all together, it happens. Maybe just speak to that real quick before we talk about you as well. When I was going to use SQLAlchemy, the main thing that I had worked on a lot at work was a lot of fancy selects. I hadn't done much work with the persistent side, but I read this book by Martin Fowler called patterns of enterprise architecture as well. It was quite an interesting book back then, yeah. And I had actually never, even though I had used hibernate, I had never heard of unit of work. And I was like, wow, that looks cool. I'm going to write that. Because one of the philosophies was like, insert update deletes are really boring. And even saying object that saved is really boring. Because I was working on a content management system for Major League Baseball. And when you work with CMS, do you have a lot of tree based hierarchical structures with lots of self referential stuff when you persist self referential structures to the database with autoimmune primary keys? You've got to get one row, get the primary key back, put it there, put it in everything's got to be done. It's so hard. Yeah, yeah. I tried to call save on this, but that didn't work because I needed to call say first there. And it's like, oh, this is crazy, right? So it's like, why would I want to do what I shouldn't have to do that either? I just had this thing that like, here's everything that transaction just push it, and it took it very long time to get it right. It has a couple of little chinks in the armor. A couple of cases that you might have to drop it to quality plus explicitly. But we never get bugs with the unit of work stuff. I had if you look at the unit of work PY, it hasn't changed in here. Yeah. It took a long time in the beginning and then I wrote it a few times and it was really bad early on. It was very hard to get it right for the summer. A lot of edge cases, right? I can imagine. Because people can do any sequence of things and then you have to make it right. Yeah, mostly that we support these joint table inheritance models were very hard for me to get my head around how to persist that and then just go along. It just took a long time because it grew organically. You know you're coding, you're doing. I'm glad you wrote that instead of me, so thank you. Yeah, I wouldn't be able to do it today. You gotta be deep in it, right? Comment from Brandon brainer. Hey, Brandon. I use SQL model in a demo project, and it was so easy to use. It's very nice. All right. So I think probably the big news over here is two O, or as you like to put it at your recent talk the 1.4 ending. Very early stages are on the site in the library tab as a development thing with development docs are nice. And the current release is a 1.41 .4. It has a lot of these features in there already, right? Yes, all of the just about everything in SQL and the two internally is available in 1.4. We did the hold the internals first and the end of the stuff so that 1.4 could be a transitional release so that all the behind the scenes would be getting tested and people could use the new APIs and transition over is too open to drop some of the older APIs hard. Many, yeah. Okay. Yeah, so people who have looked 1.4 has this big migration thing where if you're on 1.3, which is pretty common, you can go to one at four pretty easily without much problems. But right, when you're on this thing, we had this whole thing that is inspired by the python two to three process, and at the same time tries to not make some of the what I thought were mistakes of the python two three process. So what this is based on is that one type four has an environment variable you can turn on in your console, whatever, a cold SQL can be worn too well, something like that. And when you turn that on, you're now in warnings mode. You will get all kinds of warnings about all kinds of APIs that either have changed or are going away or use this order that one. So a lot has happened, but at the same time, the reason that's maybe not as scary as you might think is that all the APIs that are being deprecated, our APIs that I've already taken out of the docs years ago, the APIs that I've been telling you for years don't do that anymore. We're not going to do that. So it's.