How'd you like to listen to dot net rocks with no ads? Easy? Become a patron For just five dollars a month you get access to a private RSS feed where all the shows have no ads. Twenty dollars a month will get you that and a special dot net Rocks patron mug. Sign up now at Patreon dot dot net rocks dot com. Hey Carlin Richard here. As you may have heard, NDC is back offering their incredible in person conferences around the world, and we'd like to tell you about them. NDC Copenhagen is
happening August twenty seventh through the thirty first. Go to NDC Copenhagen dot com for more information. NDC Porto is happening October sixteenth through the twentieth. The early bird discount for ADC Porto ends July twenty first. Go to Dcporto dot com to register and check out the full lineup of conferences at NDC Conferences dot com. Hey there, this is Jeff Fritz, the purple blazer guy from like or Soft, letting you in on a little secret about my friend Carl
Franklin. You know, the guy who started dot net rocks, the first podcast about dot Net in two thousand and two. The guy who's been teaching Blazer on YouTube since twenty twenty, Yeah, that Carl Franklin. Well, Carl's joined up with the folks from Code in a Castle to teach a week long hands on Blazer class at Are you Ready to Get This? At a castle slash villa in Tuscany. It's sort of a luxury vacation with Blazer learning
built in. Carl's calling it the Blazer master Class. You'll learn Blazer from the ground up, finishing the week with the ability to build and deploy Blazer applications. Since the training happens for only four hours in the morning over six days, you can bring your significant other, your partner with you and you should right This part of Italy is absolutely beautiful. There's so much to see and do, and in Larion Marco from Code into Castle are organizing daily activities
both at the castle and in the area. The castle is in the Marema, a less touristed region of Tuscany, offering both classic Tuscan hill country as well as easy access to the Etruscan Riviera, with sublime local food, wine and olive oil around every corner. Breakfast is included. Every day there will be two communal dinners at the castle book ending the experience, and most other meals and all activities are included. And did I mention you'll learn Blazer in
person from Carl Franklin. Listen, space is limited and for very good reason. This is quality training in a beautiful setting. Go to code in Acastle dot com slash Blazer twenty twenty three that's b L A z R two zero two three to take advantage of this amazing opportunity to join Carl in Tuscany for an unforgettable week of La dolce vita while advancing your programming skills in this important new technology. Hey guess what, it's dot net rocks. Welcome back.
I'm Carl Franklin and I'm Richard Cavill and our old friend Ted Newer to see her. We're going to introduce him in a few minutes. But first, dude, what's up all sorts of things happening in your neck of the woods, particularly your neighborhood. What happened? Well, yeah, well, you know, we were getting to a weird place with where do you want to live? What do you want to do? You know, what I realized in hindsight is that the old dog passed away about a year ago, right,
and so it's just been the two of us in the house. We went from dog kat and two daughters in February of twenty twenty to jest us by March of twenty twenty two. And then there was two daughters and a boyfriend. Right. Well, they weren't here for very long. They went off into their own places. Now, husband, right, they're all they're all done. But it's like the two of us in this house is a
house built to raise a family in. Yeah, and as much as we love it and we built it like it fits us in a lot of ways, it's a lot of house. And as soon as we started talking in terms of not having this house, immediately we're talking about building another one. So so you didn't think about, you know, taking one of the rooms and making it all stainless steel and putting a villain chair in it, and you know, having multiple monitors. Well, to be clear, we had
a room for restoring looms, like that's the place we were at. There was a loom room, which by the way, had its own on suite in case we needed to go to the bathroom so that we have too much space. Two house is amazing. It is a great house, and and the buyers are a young family with two teenagers. Like it's a perfect replacement. We're moving to the coast full time. I suspect we'll build something eventually, but yeah, we're ready to simplify a little and OK with it.
I'm really happy. And then my neighbors are quite annoyed with us, But that's okay because well it's a tight knit neighborhood. As you know, you've been here. I remember the parties and stuff, and I actually attended one
where all the neighbors came over. And that's a really cool thing, you know, because not everybody has neighbors that just get together for you know, special events like sunsets, yep um, you know, and and all through the pandemic when we'd go all come out on our driveways at six o'clock with a glass of wine. Yeah, you know, that's nice toast each other and go back in hek. I love this place, and now you can
do that with the otters. Yeah. I would also say there's a couple of my neighbors literally in the cul de Sac that have places on the coast as well, so they are entirely possible to be retiring up there themselves sometime in the future. Not that I'm retiring, or arguably I am retired. This is me goofing off. What is this word you speak of? Retire? Right? Don't? I don't even know what to talk to tell you anymore? Right, I don't know what you're talking. That's nonsense anyway.
But you know you would think by getting rid of a house my project list would get shorter. You would be incorrect, sir. So it's like, yeah, now you got to clean it all up, and there's just not enough automation up on the coast. There's some automation on the coast, but there could be much more automation on the game. All right, well, enough of that fascinating chit chat. Let's get to uh that's laughing. Let's get to better know a framework. Boom awesome. All right, man.
You know, as if I didn't have enough to do, I started a new freaking YouTube show. Are you out of controller? What? I'm out of my mind? I don't know. Everybody's like, hey, is your marriage okay? You're like, you're like spending more time making shows than you are with your wife. And she might tell you that's true, but I don't think so. But anyway, I mean, the thing is you're recording
from your house these days. Yeah, it's not like you're gone, you just it's yeah, it's you're just in a little box full of foam, that's right, and in a microphone. Some fallome in a microphone, little webcam. But um yeah, So the thing is this and I got this stuff down to a science. It's all automatic as much as I yeah, I know what I'm now. When a good topic comes along, such as AI bots, and I have friends that have been into it since the very
beginning and they've done some amazing things, a show happens. So it's yeah, it's the AI Bought Show with me and Brian McKay. And Brian McKay is one of our app next guys. He's extremely smart and extremely resourceful. Um yeah, So anyway, it's at the aibot show dot com. There
should be at least three episodes up there. In introduction to chat GPT, and then in the second one we talked about prompt engineering and we used the GPT API playground to write a little three act play basically, or a three act screenplay. Everything from it helping us find the topic and the characters and the conflicts. And you know, we basically started with a one paragraph story premise and then you know, got from different acts and the beats and the
scenes, and I mean sort of that's classic writer brainstorming technique exactly. Yeah. Here you're you're storming with a piece of software, right, and he basically has this idea where you take the key ideas that you get, You say, give me five ideas, you take the one you want, you add it to the system prompt, which is sort of the backstory, and then it continues generating from there. It's just fascinating to me. Yeah, that's awesome stuff. AI bought show dot com. No, it learned to
love it. Who's talking to us today, Richard Campbell, You're gonna love this. I grabbed a comment of a show ten eighty five, so that's January of twenty fifteen. It is disturbing to me to say twenty fifteen and say eight years ago, but geez, and this is a show we did with David Simons. When I just called it different databases, right, because it's really you know, early in a lot of those conversations too about where the sequel no sequel, like who cares and generated a ton of comments at
the time I've had. I've read many of them, but this one I haven't read. And this is from Thomas Jansen, and Thomas Janson says this is close to a talk I did at NDC London, which makes me think we should probably have Thomas on the show one of these days. Well, Polyglot Heaven and considering we have ted around today like there, you know,
there's a line he's used before too. Specifically in the talk he dugged into using multiple data stores in a given application based on what it's appropriate, what's the shape of the data, what you know, what's the sensitivity and so forth, And in his particular demo for his talk he was using elastic Search
and Neo for Jay. He goes on to say, one of the things that Richard mentioned was to store objects as they were received, but better approach is to store the events as a result of the action the user was taking. I think this is a little bit of semantics, but it's good semantics. By storing the event, you get a complete audit logue of what has happened, but not necessarily the state of the object, and this is a
good thing. The reason is it's a good thing is because the state could have many things in a system depending on how you choose to read the events, but the fact that something has happened can't change. Also, these events you store can trigger other parts of the system, executing long running processes or processes that just update different read views that could be stored in sequel and the over j mongol, last research or whatever. And another thing that Carl was
worried about this particular episode was eventual consistency. And to be clear, every time something makes an action is almost always doing it on data that could be old. The important part is if you're using an event store and events sourcing, is that when you're executing the action, the action will be directed against the event store database, which is consistent. The consistent part is that the user or some other system might have triggered an action on old data. That
is something that's really hard to work yourself around. Really love the show, but also kind of a rare occurrence if you do it right. Yeah, you know, And it makes sense to optimize through the majority of cases and then deal with exceptions, and exceptions occur, Right's I mean you think about every single website you ever go to to look at air fares. Yeah, they're all lies. It's just that only because most people never actually buy the
airfas or what do you care that it's a lie? And then when you actually go to buy it once in a while, it's gonna go Hey remember that airfare we showed you? Yeah we lied. Sorry, Yeah, here's the new air fair. Somebody was faster than you. Yeah. It's just a cash failure, that's all it is. But it's best compensated with a happy dialogue. Yeah yeah, hey Thomas instead, yeah the one that costs more enough, Hey, Thomas, thanks so much for your comment and a
copy of music Code Buy. It's on its way to you. And if you'd like a copy of music Code by I read a comment on the website and dot net rocks dot com or on the facebooks we published every show there, and you comment there and a reading on the show, we'll send you a copy of music Code Buy, and definitely follow us on Twitter if you want. But the cool kids they're on Mastodon. I'm at Carl Franklin at tech hub dot social and I'm Rich Campbell at Mastodon dot social And is it
really the cool club? Because I think Threads is the cool club. Now Threads sucks. I'm sorry, it's you know, maybe it has the potential once it uses Federation and all that stuff, which it doesn't yet, but the app itself is I hate it. Let me say this, one hundred million people disagree with you. Yeah, that's because their sheets. It's a very big number. That is like a quarter or maybe even a third of all of Twitter in a week. Yeah, that's true. Network effect is
important, friend. Well it's because everybody on Instagram said, okay, I'll try that. Yeah. Well this is the brilliant I mean, listen, Zuckerberg screwed a lot of stuff up for quite a while. This is a pretty slick move. Yeah. So now he just has to fix the app so that it actually has functionality. Wow, he's got the network effect. Maybe he can. Actually he's already spend billions on an app that doesn't work. Maybe you can spend MP some money on an app that does work.
That's right, Hey, Zuck, call me, I'll fix it for you. It'll be fine. Everything's fine. Yeah, everything's fine. We're all fine here, how are you. Let's get to work. Yeah, all right, let's introduce Ted Ted Neward. How long has it been since you were on this show? It's a long time safe fifteen, twenty fifteen, all right, I'm wrong. I think it's going to be even longer than that. Twenty fourteen. He was on the panel that we did at the
end Service Bus conference. Remember that. Oh yeah, boondoggle in Brooklyn. Boy, that was a riot. That was fun. All that panel. The last full show on his own twenty twelve, ten years ago. Oh my god. So your bio has changed. It's a lot more general. But you've done so much work. I'm just going to read what's on your on your site here. Ted Neward is an industry professional with twenty plus years
I put in the plus there experience. He speaks at conferences all over the world and writes regularly for a variety of publications across the Java, dot net and other ecosystems. He currently resides in Pacific Northwest with his wife, two sons, three cats, twelve laptop, seven tablets, nine phones, and a rather large utility bill. I like that one. That's a great one. I actually actually, since we were speaking of domestic situations. I need
to revise that because one son has moved out there. You go, Yeah, so it's now it's just one son, three cats and all the rest of the paraphernalia. Well, I remember meeting you somewhere. You were a teacher, a trainer, developmentor and a consultant there and when dot net first started, you were intrigued because you were a Java guy. And then C Sharp turns out was pretty damn good. Well, so the interesting story there is, you know, I was development or teaching Java when you know,
Microsoft, all the dot net stuff was still very very hush hush. Nobody knew anything about it. But Don knew about it, and so did don knew about it? Don Box and Don Box and Cross Cells probably I think only Don to start because they kept the you know, the circle of trust very very tight back in those days. And Don was part of the Soapspec guys, he and Dave Weiner. They contributed to the soap specs, so
they were naturally pulled into the process. Yeah, and so we were down in LA for a instructor retreat and Don pulled a bunch of us, you know, basically put a piece of paper in front of us and said sign this or you need to leave the room. And it was an extension of the NBA to allow Don to tell us about this forthcoming dot Net thing, which back then was still they hadn't quite figured out the names, so it was like next generation services. Yeah, well the first version was window services.
They you know, consent decree web services. Yeah, oh, they went through. That was actually one of the t shirts that we had at one point was all of the different names Calm three com plus all of them xed out, mgws UT, Universal Runtime xed out. Yeah, And so it's you know, it's part of the reality that dot Net was on an intentional product, like the Universal runtime was addressing a Windows problem and had nothing to do with needing an alternative to Java and had nothing to do with wow,
our web tech sucks. Like the fact that they all came together is kind of miraculous, although there's very much a Conway's Law effect of that's why there were too many teams involved in a lot of the architectural decisions are a bit odd because they had to do with the team with the idea had to be the team implement and even though it was in the wrong place, so many. Anyway, that was here introduction that dot net and uh we we
interviewed you early early on in dot net Rocks. Oh yeah, Mark, don Yeah, I think I've actually done a dotnet Rocks with all of your co hosts. I did one with Mark, I did one with Rory, uh and Richard. I've done several with Richard. That's just pretty special. Yeah, I'm kind of surprised you've done several of me. Uh. Well, I just like you, Richard. I don't know if that's true either.
Man. There are very few people, very very few people in the world that I invited to my fortieth birthday party, and only one that I asked mc the roast. There's that. Yeah, that's mostly because I don't think that's almost kind of a punishment. Actually, although I didn't spend time with your sister, and your sister is awesome. Well, but here's the thing that I know about you, Ted, and then that we can you know, your bio doesn't really explain it. You are like the polyglot.
You all of these languages on top of the JVM. You know a lot of languages on top of dot net, some that aren't even on dot net. You know a lot of different languages, a lot of different technologies. You were sort of you were the anti o RM guy back when you and
or and Eeny had that slap smacked down show Canada. Yeah, of course, but I mean you were the guy who's like, start procedure, start procedures, and Aran's like no, and then you know, that debate raged on for a while and now you're you're You're back here to talk about couch base. Well, so part of the thing is I've always looked at technologies and particularly new stuff that's coming down the pipe. But more importantly, I think it's the way to describe me. The polite way is to say philosopher,
the more accurate ways to say contrarian. So back during you know, the two thousands, particularly in the Java space, everybody was going hog wild over enterprise Java beans and object relational mapping tools, and I was trying to point out that there are significant costs to using these things and to say don't
don't just take it by default. And so yeah, that's when I penned the you know, object relitional mapping is the Vietnam of computer science, for which for which I am, that is still the thing I am most widely known that that actually earned me an entry in Wikipedia. But that was a point in time, like you're pointing out, right, things change and things evolve in some things that weren't working is so well back then got fixed and
you know, new technologies came out around it. Well, part of the thing is we have to be a little bit careful because yes, we made changes, but there are also certain properties of the universe that are immutable, such as the speed of light. Right. The fallacies of distributed computing are always going to be there because as soon as you try to go from one machine to another, it gets very very expensive in time and energy and bandwidth
and so forth, compared to within the machine. I mean exactly, exactly. Often we're only slicy seconds here, but you're going from nanoseconds to milliseconds in a lot of cases, and as soon as you change orders of magnitude like that, you know, And and the big concern was that a lot of the rms at the time, you know, lazy loading was the word of the day, and so it'd be like, oh, well, let's
go fetch one property at a time. So you're making all these trips back and forth between these two nodes and the network and suddenly wondering why your system is slow. This holds, by the way, whether we're talking about you know, databases, whether we're talking about web services, whether we're talking about you know, grid computing. If you remember that phrase from way back when you know cloud it, as long as they are just bo stuff bingo,
right, these these things still hold. And so you know, part of part of what I've always tried to do is to look at things and say, all right, you know, the yes, there is a mainstream view of things, but how do we you know, let's get out of the mainstream for a second, because it turns out the eight twenty rule still holds. Eighty percent of what anybody does can probably fit in the mainstream. But
then there's the twenty percent around the outside edges that don't fit. And so this is where you know, particularly as I started looking into databases, of course, I was looking at all the Nosequel at the time, right, and there are tremendously useful things about a Nosequel database. You know, you
look at mongo dB for a second, the documents shape of things. Before we get into that, I want I want to go back a point where you were talking about how certain you know, constants like the speed of light and being chatty and all that, And I think that I a sink innumerable changed a lot of things, don't you When we could do streaming either locally or over the internet, that did. I mean, you know, it's sort of a nice answer to lazy loading when you're talking about data that it's
it changes things. I'm not necessarily going to go so far as to say it, you know, it solved all problems, but it's certainly you know, it changes where things occur and how things occur. Right, Yeah, you know, a lot of this is borne out of the whole reactive programming space and reactive you know, and many responses says we're still going to pay the cost of time in terms of data moving over the network, but we're
going to pay it differently. Your users aren't going to notice it. Let's put it in a perfect world ideally, right, But I mean, you know, if an interesting experiment that I often do, because one of the things I've done since we last talk is is I actually am a guest lecturer at the University of Washington, so I'm actually talking to undergrads on a regular basis, and spring quarter I was teaching distributed systems, and so one of the things I was pointing out is, you know, yes, there's the
cost of sending all this stuff across the network. But let's do an interesting experiment. Bring up the Amazon dot Com homepage. But don't look at the actual center of the browser. Look at the bottom, look at the status bar right because it flickers as it loads various images and so forth. And let's count how long it takes to actually fully load the Amazon dot Com home page. And it's measured in seconds, and it's not single digit seconds.
But what they do is they load the first you know, first page, if you will. They load the first that you can see very quickly, yes, and then they go fill in all this other stuff and a synchronous link right by the time you scroll down, bingo, you'll see it. And it would you would think that it's been there all along, when in fact it just got there right right. And in many respects, it's a
brilliant use of asynchronous you know loading. To say, most people aren't ever going to go below the fold anyway, So let's load all that stuff after the fact. But let's make sure that that above the fold. The first I don't know, eight hundred thousand something pixels that loads immediately, right,
that that loads as fast as we can possibly get it. And and there are so many ways that you can approach the design of a system, the design of a page, of your user interaction, whatever you want to call it to, you know, to reflect that. Right, that is clearly somebody who sat down and looked very very much, not just at the numbers in the system, but the way people were interacting with the system. All right, could talk next next Now you were talking. You started talking about
manguid B and and all that stuff, and I interrupted you. I apologize. I mean, the big thing was, you know, when no sequel came around, Right, Originally the was to release us from some of the things we were doing with respect to transactions and to be able to get to some of that eventual consistency that you were talking about earlier. But along the way, you know, when somebody said, okay, we're going to break away from the relational database. Here's an opportunity. Let's really break away from
the relational database. And so they started changing up the data. You know,
the data shapes, the data models, right. So now instead of it always being relations and relevars, let's look at documents, let's look at graph let's look at and what I'm seeing now personally looking at some of these different databases, and this is kind of where I got into conversations with couch Base, and I'm working with them to kind of, you know, introduce them into more of the university setting as part of my stuff at Utah.
You know, different databases are now actually allowing us to do a certain amount of combination of various things. I mean, before it was you got relations in relev you had transactional, and you didn't even see the storage engine. That was just you know, a baked in, opaque property of the database.
Today we are seeing databases being able to plug some of the storage engine, you know, so like my sequel will let you choose which storage engine use, We can decide whether we want to run a cloud or on prem We can, you know, we can make all of these interesting decisions either
between products or within products. But more and more of them are starting to go the whole multimodel route, right, which is one of the reasons why couch is interesting because early no sequel said, yeah, Okay, we'll give you a document model, but you're going to have to write a lot of code to query it, right, you got to do this query by example stuff. And you know, couch was one of the couch Base. I have to be careful because there's couch base and there's couch dB and they are
very very different things. Ok. The couch base guy said, no, no, no, we can we can give you your sequel or a sequel like dialect. We can give that to you, Nickel, and yeah, exactly, and I can go, yeah, go go get it, go go queery to your heart's content. And you know that in many ways addresses
some of the concerns people have. You know, couch based supports, you know, some of the traditional relational view of things as well as you know, they've got some degree of graph I don't know that I would go so far as to call it a full graph database. There's also a link to couch base tool out there, so you could use your good old familiar link
syntax, which is very sequel like and very functional. Yeah, yeah, you know, so this I mean to me, this is interesting simply because it means that it opens up a whole lot more in the way of opportunities to choose things. You know, twenty five years ago, if we were talking, the only choice you had with respect to where you were going to store your data is which relational database were you going to use? Right?
Was it Sequel server? Was it Oracle? Or maybe if you were really heretical, you chose one of the open source ones, right, my Sequel or postgress right today? Oh you didn't even say dB two. I didn't know what's wrong with that dBase? Oh well, you know, IBM. IBM just decided. IBM just decided that they were going to charge for red Hat Enterprise Linux. So now they are dead to me that that's that's what's
going on there. Um, you know, I mean the the options available, And frankly, that's very intimidating to a lot of people, right. There are significant number of developers and architects out there who find that choice intimidating because it's like, what if I choose the wrong one? Yeah, because we all know how changing the database sucks. Like that's a brute that's a brutal prospect. I don't know how often they get to even choose. We're
paying for sequel server licenses. You will store your data and sequel service. There is that too, Yeah, yeah, there is that. Although the joys of microservices right now persistent. This is all you know, an internal detail, right it's encapsulated away because it's all part of my microservice. So you know, yeah, well that's for those that are doing microservices. There's
a lot of us out there that aren't. Well. And I would also argue it's one of the reasons that the open source database took off because the license hammer is defeated by but it's free, right right right, I can't argue with that. Yeah, So, you know, I mean the in the case of couch base, you know, I like some of the decisions they've made. Um, you know, I like some of the people that I've talked to. There are a lot of other, you know, viable
tools to use. And as a matter of fact, one of the things spring Quarter I was also teaching a data and databases course to the kids that you do and teaching them relational databases. I use Sequelight because well it's free and frankly it's low realized, and so suddenly it opens up a whole lot of opportunities to avoid making those round trips and I saw a great Lettle meme that said every time somebody says this meeting could have been an email, there
is somebody else saying this database could have been a Sequal Light. Yeah. Right, Well, you know, if your database as one user, and you know where so many databases have exactly one user, you're holding it in your hand, voice the phone, the phone. Yeah, well you're holding it. You're well I was holding it, yes, but you know, I'll pick mine up two just to be here you go. I'm just running
down the sort of the features of couch Base. Obviously, it's a document oriented distributed so there's a distributed architecture, so it can scale horizontally, right, And depending on where you're running it in on what hardware or if it's a cloud thing, all the cloud providers have services for it in memory optimization.
Right. So if you could think of it like, oh, load of Jason file into a dictionary, there's your database, right, And then there's this Nickel NYQL query language which is kind of like Sequel but designed for Jason data synchronization. Couch Base Mobile, so a mobile database like you were talking about Sequel, you know, Sequel Light, but this is a couch based light and a synchronization gateway so that you can do that. And then
of course it's got integrations and SDKs and all sorts of stuff. And I also mentioned before this link to couch base, which is good for dot net developers if you're used to link, right, So yeah, it's it's pretty
cool. The other thing I know that that the couch based folks are talking a great deal about, and you know offering is Capella, which is there cloud hosted flavor of I mean, you can certainly a couch base to run in your favorite abs ash or whatever, but you know what is the practical difference between you figuring out which version to install and just letting couch base deal with it in their cloud, right well, and just add option to just
go, hey, I don't have to decide now we're just running this in the local rig while we're figuring stuff out. But when it comes to scaling, it's like, do I really want to build it this infrastructure? Can I just shift to the services model? And it's a database as a service. Pretty awesome and gentlemen, and I'm gonna use that term very loosening to day. I need to interrupt from one moment for this very important message,
and we're back. It's dotting that Rocks. I'm Richard Campbell. Let's call Frankly and our old friend Ted Neward, who only careful with that old careful with that old emphasis on the word old. Boon at first show was fifty nine, which I think is actually rary at that point, but you know, he's pretty close in that ballpark, and we're talking a little bit about the modern data landscape. I think more than anything, just that you know,
different ways to store. I really like this multi model mindset, just that what engine would you like to use? What form would you like the store? I mean even sequel servers headed down this path. He yeah, oh you know like it. Now that you say it, it's like, wow, that's really what's happening with data stories these days. It's like, well, what do you got, Let me hold it for you, let
me index for you. And this is where you know, some knowledge of database internals will help, right, because one of the things that we saw you terms of well, let me back up for a second because earlier you talked about the comment from Thomas and I can't remember his last name, sorry, and he was talking about polygot persistence and storing data in different databases. One of the drawbacks to that approach is the fact that in many cases,
trying to do so a TOM across these different databases was tricky. And so if I were storing something in my document that also needed to modify something in the graph, Okay, in one case, I'm doing it to a couch dB, in the other case, I'm doing it to a NEO for J and making sure that both of those got updated or neither did was always a little problematic because you're going across databases, and we didn't in the early days
really have distributed transactions across different no sequel databases. When the database vendors started to embrace this multi model thing. Now it became possible to do that atomically because it's all inside of one transaction manager, the one database, and still have some of your multimodel. But you have to be a little bit careful because how do they store things internally is going to really affect some of the performance, right most right, Like, for example, there's no data or
time types in couch base right right. Oops. I just think you quiet walk past the real estate, which is life is too short for distributed transactions. Well there is that, there is stuff. Once upon a time, you know, I crushed my soul trying to make DTS work, truly try to make it work. Oh, we all did. We all did because truthfully, you know, that was that was what we all of us believed and taught everybody else. And what was the I mean, the canonical example
for transactions banking? Right, Yeah, I'm going to make a deposit to you. So we're going to take out a lock and we're going to make sure that we remove the money from my account and deposited to your account. And the great lie behind all of that was that's not actually how banking works. It never has. It's you ever been a thing exactly exactly. Oh and by the way of using JavaScript for those floating point data types, you
got another problem. Well there's gonna be some funny look at penny shown up real time. Now there are those problems that we inherit, and there are those problems we make for ourselves. And let's let's if you're using floating point in any language, in any language, for money, we have a yeah, seriously experienced tip. Money is not floating point. No tip for you all kids, right, don't count dollars with fractions of a dollar. Count
pennies. It's all pennies, right, One dollar is one hundred money units, you know. Yeah, I mean going past the whole transactions thing, distributed transactions thing, right, especially because when we needed to scale, contention is the enemy of scale, right, you know, just repeat that to
yourself over and over and over again. And you know. The the multimodel databases allow us to you know, work with all these different shapes of data, but deep down, you know, obviously they have to store data somehow, and this is why a lot of the early multi models were built on top of key value stores. Right here is here's a primary key and the rest of it is a blob binary and you can interpret that however you want. But every time you fetched that, it had to be repounded into shape
before it gave it back to you. Now, some of the databases seem to be experimenting with more in the way of you know, like like actually storing it differently with indexes and weird places. So it's not just one storage engine. They're actually using multiple storage engines depending upon what you're storing underneath there. And then and a unified intacting strategy, right right, right, right,
right, So it's just really just a performance thing. Just Hey, let's take the shape of data and store it in the closest thing to its natural shape. I think that that's where you get the best performance generally speaking, right, because the customer doesn't care. They just expect us to store the data and be able to retrieve it, and sooner would be better and right cheapest possible, please, thank you very much. Yeah, cheap is
also handy. Yeah, yeah, well, and I think you know, all of this is still relative, right, because so much of this, you know, so much of the performance of your queer could be drowned out by the length of time it takes that web request to arrive at the page and then get back to the browser. So again, go back to what
we talked about earlier, the Amazon story. Right, In many cases, let me just fetch an initial set of data, get it back to you, and then we can go get more later if you need it, right, yeah, and do so asynchronously in that sort of reactive model that Carl
talked about. But part of you know, part of what any system designer, part of what any architect needs to do is figure out where we need to be really responsive and where we can do that asynchronous loading, and in many cases with databases, we can do some of that by saying, let me query what I'm looking for, but then let me also pull back some
additional data, but pull that back asynchronously or what have you. And this applies not just a databases obviously, web services and Jason services and blah blah blah blah blah blah blah blah blah. You know, do we still love Jason in twenty twenty three. It's just a data form. I mean I never fell out of love with XML. I never fell out of love with CSV. I love hard with We have issues, man, you're just a You're just a love them and leave them kind of to me. Yeah,
you know, but Jason I never had a problem ever. Okay, No, I have had problems with Jason. I have had problems where by default a serializer a de serializer changes the case of properties to to camel case when that's not the case, that's not what they are, and therefore it fails. Yeah, I have a problem with that. Well, see, here's here's the fun thing, right, because XML could actually account for that, for you because XML has something that Jason doesn't, which is the opportunity to
capture metadata directly in the format. Right, And I find it absolutely telling that you know what people are working on right now, Schema for Jason. Oh god, no, wait, well it stop stop. How many times have we seen this? This is the path to hell? You know, it would be even more fun. How about schema for XML? Could we do that? That would be really fun. Let's do that, hey man,
Schema for XML. You know, it was, it was, it was incredibly I'm not saying schema for x MEL didn't buy me a car because it right, right, But it doesn't mean it was ever a good idea. Right. It's self defining. But here's the thing. Here's the thing, right is, first of all, the idea of schema itself is not bad because it allows machines to be able to do a bunch of the work we would normally have to be verifying. Yeah, right, exactly validation.
And where the XML Community committee I think got XML schema wrong as they tried to write XML schema in XML. To be fair, it's because they wanted to do everything in XML all the time. We just kind of started you know, believing our own stuff. Now I need a scheme for my schema. Well, and you know who else did that is the Sequel Committee, right, because they want, you know, they want schema to find within the sequel language itself. So they just created a whole bunch of new keywords
and so forth to do it. You know. So this notion of trying to get kind of this linguistic closure that we can define the language inside the language. It's I see what you did there with that language reference there, I saw that. I got you. I'm onto you man. You know, it's an interesting idea, and I don't know, you know, I know a lot of language designers find it to be really interesting and elegant. I don't know how much. I don't know how how much that elegance actually
pays off in the long run. Yeah, you know, but at the end of the day, they still go after it. And you know, Jason ld I think it is is the schema for Jason. I think they're trying to do it in Jason at the same time. And it's like, you know, maybe it's not bad to just have a different definition, but please, please, please please please don't don't throw yammo at this particular problem because that's just this. Oh God, I was waiting for you to bring
up that awesome, awesome language. I cannot stand. M loves you. But these are all just representations of data, right, And you know, I really want us to stop, like, you know, reinventing new data formats to do the same thing and then arguing about it. That's what I'd really love us to do. Can't we all just get along? We could have cured cancer by now and we had taken all this energy around data formats and just put it towards you know, identifying human Gino. Anyway, I'll
get off my soapbox. Okay, yeah, So, so, um do this couch based cloud database as a service I think available Capella. Yeah. I think it's available on all the cloud platforms, as well as the you know, couch base cloud thing, isn't it. I don't know officially, I've I do not work for couch Base. They do not. They do not you know, give me benefits or anything like that. So I'm not
a salesperson. I don't know the full details, and I don't have their website up in front of me. I would believe it if you told me though, because I know they've been pretty comprehensive. Yeah. Okay, so so here's a story from on couch based dot Com from January twenty twenty one. Couch based Cloud now available on Microsoft Adger. Yeah okay, yeah, So I think part of the idea of cappella is you are treating couch base as your cloud, but you could probably specify which cloud provider you're in,
But don't quote me on that. I don't know that for sure. Yeah, it looks that way. So run couch based multi cloud across AWSU and GCP, so you could do that. There you go, And I think they're already by the by what you've said and what I remember conversing with Matthew Groves, who is one of couch bases more public figures, I believe part of what they're trying to do there is automatically incorporate some of the multi cloud
strategy that people often talk about for greater reliability. Right, So yeah, I think so too. Yeah. I always question that one because the cloud's out relying all of our data centers, like come on, it's a pretty big overhead to take on. But I make to me having the checks box at him there at least is a good idea. Whether or not you actually want to pay for the implementation is another question entirely Well, it kind of
goes back to two things, right. Number one the reliability argument, which, given how reliable all three of the big cloud players are already, I'm not sure if it's worth it. But the other is vendor neutrality. Right, so that if AWS decides to pull an oracle and bump their prices up by you know, ten thousand percent, you can say, yeah, okay, we'll just flip over here to Azure, flip the switch and we're there.
Yeah. But again, like you said, you know, you pay a price for that, right, And vendor neutrality is frequently we got the job of folks in trouble when we tried to be vendor neutral, right. I mean that was part of the whole or an i ny discussion way back when was stored procedures were intrinsically tied to a particular database, ures you automatically weren't vendor neutral. So therefore stay away, said the Java community. But
also, I mean he wanted to have sequel in his app. He wanted to generate that sequel dynamically, you know, in the RM because that's how they work. Yeah, and you know if he has to go through stored procedures, that adds a level of complexity and blah blah blah blah. Yeah, and it it violates encapsulation, right, you know, just to go back and put my little whip cream in a cherry on that because if you well, I mean I still remembered back in back in ninety ninety seven here
from another planet. You know, I was good till the whip Cream showed up. Everything was come on, cream show. You are not so naive as that Richard Campbell. You know if you've ever been have you ever been sitting in your cubicle and had somebody call you up and start yelling at you because you broke their mission critical app And you responded with I'm sorry, who
are you? And they're a VP from like four organizations over because your boss's boss's boss decided to give away the schema to your database and then you changed it because you needed to add it's it's encapsulation changed to sit that way too shortly. My line was always I'm sorry, who are you? And why shouldn't it tell you to get stuffed? Yeah, that's why I don't make it incubica on that second part of it. Yes, well, yeah, there are very few people in the world who are less less tactful than me,
Richard Campbell. I'm not saying you're one of them. I'm awful. I'm offen tactful. But you know, so what he gone when I see what? All right? So, what the hell are we talking about with the whip cream in the chair you're gonna put on top of that? I was just gonna say that whenever, whenever you have a relational database, your schema is your is what you seek to encapsulate. Right. That was part of the whole reason for stored proxy is they act as an encapsulation layer.
And you know, if you don't care to encapsulate your relational database, that's fine. Just live with the consequences of vps calling you up and you know you resisting the urge to tell them to How did Richard put it? Get stuffed? That's right, get stuffed that the day is the polite version for a podcast? Yes, there you go. There several of the versions. I'm sure the listener can contemplate exactly. So what if you're new to the whole. I can't imagine you're new to it. But what if you've never
used a document database before. What are the sort of the reasons that these things have become, you know, really popular. So part of the thing is the document model, the document data model is it frequently lines up with some of the things that we're doing. Uh So, for example, the canonical example for a document store is a blog. Right, You're maintaining a
weblog. Each entry is a document in the blog, and there's a bunch of information around that particular entry, who wrote it, when they wrote it, you know, the tags that are for that particular entry, etc. But the what I've found the blog entry, I want everything about the blog entry, and so I can fetch that back as a singular document, right. And there are a lot of cases where when I'm looking for a thing, I'm looking for that one thing, so frequently a customer's order history.
Right. When I'm looking at the order history, I'm often not looking at the I'm not looking across the entirety of all customers to figure out which customers have a history of ordering toilet paper. I'm looking at this particular customer's order history because I want to you know, look a look at their list of purchases because they want to dispute one or something similar. And so if you're if sort of the natural data model that you're working with is one that has
kind of a central piece to it with some ancillary data. Yeah, a document data model would work. If you've ever built a star schema in a relational database. I would argue that you are actually building a document model in a relational database, and in the end, as a developer, you get back a list of objects which are essentially documents in and of themselves, right,
I mean, it's just another way to think of it. But you know, we're using Jason all the time, right to persist and serialize and de serialize, and so, you know, actually taking something in Jason and stuffing it into a relational database actually in twenty twenty three seems kind of strange if you think about it. It takes time. Yeah, right, It's not just the esthetics of it. It's the fact that you have to do,
like you were talking about earlier, I have to serialize that. I have to take this object model, which could be cyclical by the way, which Jason does not deal with well anymore than exemel, did I have to take this object model pounded into the document model of Jason and then ship that when it comes back, I have to somehow rehydrate it back to my object model when it would you know, in many cases make a lot more sense to take this and store it oh natural. It's one of the reasons why
I loved object databases back when they were popular. Ye because writing code and droversy sharp. My schema is my class. We're done here right right, and so it saves you time and energy and effort, both at runtime as well as during development, if you can store the thing in its natural state. So I remember talking to Ornini Beck and Richard probably does too in about raven dB and all the questions that I had, Like, you know,
one of the benefits of sequel server is indexes. You can index fields that you're going to do queries on, and then they create these separate databases or separate tables called indexes, so that they can be looked up quickly. And you know, I quickly found out how how useful an index is when I did not index a date field in the old dot net rocks you know thing,
and then I want to do a query. And this was like on requests, Like I had web requests in a database right with a date, and I wanted to do a quarry to see how many you know, hits we got between how many downloads we got between this date and that date. And it was like, you know, you know, like sitting there waiting and waiting and waiting. So I asked, Uren, you know, how
does how does the document database deal with that? And I don't know if couch base and Mango do this, but raven dB basically looks at what you're doing and what you're quarrying and builds indexes on a low priority background thread in the background. Do they all do that? Now? So different databases will do different things, right, And a lot of this is up to the database designer. And as a counter example, I will give you couch dB,
which again is different from couch base. World's worst naming decision by the way, couch base, yeah, you know, naming yourself after something else. But in couch dB, they actually what we would think about in terms
of indexes and so forth. They call views, and they build them ahead of time, and every time you insert or remove data, they modify the view and so there, they are choosing to optimize for reads as opposed to doing that look up at later, you know, because it takes time to do that when you write something into the database serviously, right, So it really is one of those things that the database designers can do, you know,
based on the decisions they want to make. Right. So, in the case of RABDB, if they do that indexing on a low priority thread, their assumption is that you're not going to immediately query along these indices once you've put something in, or they're willing to take the performance hit, you
know, while we're doing this. Other databases, you know, particularly a lot of the relational databases, because they wanted to maintain those acid level semantics, they would do that indexing during the query and not return to you until all the indexes were updated and everything was correct. Kind of and I'm like, well, it depends on what you want. It kind of defeats the purpose having an index, right, Oh, the first time you actually query
with these fields, yeah, you're gonna have to wait on that. We'll be back to you in a few minutes. Thanks. Well, and that's why the RDBMS said, we'll update them all while you're putting the data will make sure that the index is always ready to go. So you come back and issue a query right after doing that, insert updata, delete, We're ready for you. We're good to go. You just paid for it though
while you were waiting for that initial data modification to okay. Different databases will make different decisions, and that's you know, that's part of the Just like there's certain things that are fun from a language designer's perspective, this is part of the fun a database designer is to say, I'm going to choose you know, or in some cases, I'm going to make that slider available to you the DBA to be able to decide where do we want off them?
So you know, of obviously a lot about these different things are Is there anything in couch base that you wish they would have done differently or better or other? You know, the I have become enamored of graph databases in general. I think that the graph model is one that is actually probably the hardest to replicate in other data. And how's that different from the document? Instead of pointing from one document to another, you duplicate it and have a tree
for every record or what. So a graph database is something that will support cyclical references very easily. So the canonical example here is, let's us that we want to represent, um, you know, the six, the three of us and our respective spouses in a document. And so we have person, right, I'll use the the XMLA. We have an XML tag called
person first named Carl, last named Franklin. Now you're married, so we'll have a spouse field there which has you know, first named, last named spouse, which has you first named, last named spouse, which has her, And suddenly we get into this deep infinite recursion. Right, So either we can't really represent persons. The way we think of ourselves is I have a spouse that is a property of me, the person. Whereas in a
graph database, fundamentally the data structure is nodes and arcs. So we have node first name, you know, Richard, last named Campbell, and then we have an ARC to another node first named Stacy, last name Holt, and at arc can have in fact data associated with it, such as beginning of the marriage, you know, and if if they get divorced, end of the marriage. So the ARC is sort of like a relationship, right, it's a connection to connection between these two nodes, right, at it.
And so if you've ever tried to model genealogy data, if you ever looked at a you know, genealogy database, particularly because you know, in some cases, not only can two people have been married and then got divorced, but they could get married again, right, and so those would just be two separate arcs or one arc with a begin and begin end. It's like going to the fridge and saying, oh, this milk is spoiled. Well maybe tomorrow really fresh, right, yeah exactly, We'll leave We'll leave
people's you know, life choices off to the side. We still need to be able to model it. And so graph databases do that. They handle those cyclical relationships very very well, much better than Jason. And this is funny because Jason an ex Amel are very similar in the sense that they are both kind of a hierarchical and must form a tree. Yeah right, exactly exactly. So that's the one thing is I wish couch Base had, you know, I wish they had a little bit better in the way of graphic
support. But that is one of those things that's very very tricky to store, and particularly to do so distributed. And so you know, there are certain points at which you say, if I want to be everything to everybody, I'm probably going to be not very good to anybody. I'm trying to
think of how I would approach that relationship thing. With spouses. You would probably have like a groups, you know, table with person IDs basically, right, So you'd have a group and then this group name is spouse or whatever spouses, and then you'd have the people that are because now you get into right, what if you're polyamorous? What if you have two spouse which
is legal in some states. Yeah, I guess we were talking about data sooner or later than many too many conversation was going to come well you know, yeah, I mean it's it's um there there have been ways to be able to model graphs in for example, a relational database model, and Joe Selko has a book that is about as thick as your head and that should tell you how to do it right exactly reading this for a while, yes, exactly exactly. Well, friends, Yeah, I guess that's a conversation.
I missed you guys. We need to do this, absolutely sure. I missed you too, man, So well, thanks and come back soon. I will be happy to come back what's what's your schedule look like tomorrow? Come on over next day. I got a barbecue there. You go, all right, it's bound to be some smoke. Meet around here,
something absolutely there and we'll see you next time on dot net rocks. Dot net Rocks is brought to you by Franklin's Net and produced by Pop Studios, a full service audio, video and post production facility located physically in New London, Connecticut, and of course in the cloud online at pwop dot com. Visit our website at dt n et r ocks dot com for RSS feeds, downloads, mobile apps, comments, and access to the full archives going back
to show number one, recorded in September two thousand and two. And make sure you check out our sponsors. They keep us in business. Now go write some code. See you next time. You got a dead metal bands down. Slama is hard