What's the Technology Behind Our Apps?

Julien Castiaux: 0:00

So the Python framework in big is everything that developers use to do applications in the back end. The software that Odoo is called by the Academy as highly configurable software, also called a software prOdooction line. You have one software, one generic software that you can customize depending on the needs of like the customers or the user generally. So that's a suite of different applications that can work alone. But the willpower comes when they work together. To make them work together isn't very well compatible with all the existing frameworks out there. So we had to make our own at some point. So we decided to create classes at one time that will inherit from like all the classes that are actually in use. That's the single thing that made Odoo what it is today.

Olivier Colson: 0:52

Hi everyone, and welcome back for another Tech and Dev episode. Today we are joined by Julien Castiaux, developer at Odoo. With him, we'll discuss the technology behind the audio applications. Maybe you don't know it, but at its core, Odoo is a single application that can be declined in a multitude of different others depending on the user's needs. Another interesting topic today. Right? Ready? Let's go. Hi, Julien. Hi, Olivier. How are you going?

Julien Castiaux: 1:16

I'm fine. And you?

Olivier Colson: 1:17

I'm fine as well. So what are we going to talk about today?

Julien Castiaux: 1:20

So we're going to talk about, like, all the technology that is behind Odoo. Okay.

Olivier Colson: 1:25

The magic behind the curtain.

Julien Castiaux: 1:26

Yeah, the magic behind it.

Olivier Colson: 1:28

So first, a few words about you, maybe.

Julien Castiaux: 1:31

Yeah. So I'm a software developer at Odoo. I've been working there for five years. I started as a bug fixer, so people would show up, say, Oh, yeah, So when I print this invoice, there's some information wrong on it, and we will look it up and say, okay, yeah.

Olivier Colson: 1:47

And that's how we met.

Julien Castiaux: 1:48

Yeah, that's how we met. And so to make sure like the customer is right and to fix the bug if bug there is to Yeah. To understand like all the, the business behind it. Okay.

Olivier Colson: 1:57

You're not doing this anymore, right?

Julien Castiaux: 1:59

No, I'm not doing this anymore. So at the time we, we were in the same office with like the python framework. So the bug fix and Python framework in the same office, I befriend them. So like, we enjoyed working together with the guys at the Python framework and at some point I moved to to the team.

Olivier Colson: 2:15

You felt the call of the framework?

Julien Castiaux: 2:16

Yeah, I felt the call of the framework, yeah.

Olivier Colson: 2:18

And you wanted to work on that specifically, or it was.

Julien Castiaux: 2:21

I was willing to work on technical stuff, like really technical stuff. So we have like a bunch of things at Odoo.

Olivier Colson: 2:29

That was yours?

Julien Castiaux: 2:30

No, no, that's not. What I mean is like, there, there is like room for improvement even in the framework. So yeah, I'm enjoying working there.

Olivier Colson: 2:38

That's cool. Could you tell us a bit more about what you're working on every day?

Julien Castiaux: 2:42

So my job in the team is to work on the Http stack and the Smtp stack. So I'm mainly like maintaining like the web framework but from a backend point of view. Okay, so we, we receive a request, we pass them, we route them to the correct controller like the controller. That's, that's the part of developers who do applications whatever like the controller needs to do. And then, like we receive a response, and we forward it to the client, to the bapplicationsrowser.

Olivier Colson: 3:12

Maybe it would be interesting to explain what the big scope of the framework is before going further so that people really understand what we're talking about.

Julien Castiaux: 3:21

Yeah, so the Python framework in big, it's everything that developers use to do applications in the backend. Okay. So we have also the JavaScript framework, but that's for the front end. It's not the whole team and we mainly maintain like the arm that's the, the API between like a Postgres in SQL and the developers would like to, to work with classes, regular Python classes, and object Et-cetera. And the job of our team is to maintain the API between the two so developers can like use classes and we translate everything they do with classes on the fly to SQL.

Olivier Colson: 3:58

Because Odoo is is making its own orm.

Julien Castiaux: 4:01

That's also is making its own orm. Yeah.

Olivier Colson: 4:03

Okay. And could you tell us why actually because there are standards in the industry. There are other solutions that are made by other people and.

Julien Castiaux: 4:13

Yeah, sure, sure.

Olivier Colson: 4:13

Technically working. Why isn't Odoo using them?

Julien Castiaux: 4:16

Yeah, that's a common question. And the thing is, Django is perfectly fine. Sql Alchemy is perfectly fine, but like, it's perfectly fine to do one application. Okay? And the business of Odoo is to, to do an ERP so that a suite of different application that can work alone. But the real power comes when they work together. Okay? And like our approach to make them work together isn't very well compatible with Django SQL Alchemy and like all the the existing framework out there. So we had to make our own at some point.

Olivier Colson: 4:53

And what is this approach exactly? Why is it special?

Julien Castiaux: 4:57

The business is about like doing application. For customers. Okay, But depending on your company, you will have different needs. Okay. Maybe you're like a carpenter and you need to know. Yeah. So I'm moving my man to that field so they can work on a building. Okay. And so you have to follow them. You have to. To give them instruction on the field. Okay. So today you are working there. The next day we will be working over there. And that's very different from like, from a physicist when you just have like people like showing up at your office to get some medical advice or medication or etcetera. That's two different business and they are very different. And so their needs are very different. Maybe like the Carpenters doesn't need like to, to have like a cell application. It doesn't have to have an e-commerce, okay. Like the physicist doesn't need to have like the field service application. Okay. But he will have to follow like his customers. So yeah, sick people, patients. Okay. And so different needs for different applications. Okay. If we had to make like one single application to answer all the needs of all customers, it will be very complicated. And like basically all of odoo wouldn't be used by most of customers because they will they will use different areas of the application. So our idea was to make like dedicated application. Okay, so we have like a CRM application that's dedicated to do CRM stuff. We have an e-commerce application that's dedicated to do e-commerce stuff to customers, can decide whether to use or not use some application. Okay, so they just install the application they need and our objective is to make them work together. So only the application to install and that's it.

Olivier Colson: 6:43

Okay. Okay. And so that was basically to rephrase what you just said, to avoid having like settings everywhere, fields everywhere, things to complete everywhere that actually no one is using and that a single user of Ojukwu would use only like 1015% of thing all the time and just ignore all the rest on the screen. Right? Yeah, that's it. Okay. Okay. I guess also for integration between these apps, something needed to be done because when you install, I don't know, a website next to accounting or e-commerce next to accounting, you expect something to happen, right?

Julien Castiaux: 7:15

Yeah. Usually in the industry when you so you have your application that's just an application that just do CRM and the CRM very well. Okay. But doesn't have like an e-commerce application. Now you have you have a lead and, and you sell something to the person and you you want to see on the sale application what you sold them or how much, etcetera. Okay. So you need another application and then you have like this import export nightmare. When you have like one application, you have to export the, the data like in, I don't know, Excel or CSV and to import it in the next application. And you have to to do like the work twice because you have to export the information in a certain format and then you have to load it to the next application in like the same format, but you have to make the two work together. Okay. So there are, there are some application that that try to integrate with one another, etcetera. Okay. That's complicated. That's not always well maintained, and that's what we do at Odoo. That's our business, is to make sure that like all the integration between all the apps is simple, stupid. Okay? So when you want to have like, okay, so you need that sales application, you just go to like the app menu and you click on install. That's it. And like the application is going to take like 15 seconds to install and then that's it. You have your application, It's working, it's integrated already with everything.

Olivier Colson: 8:37

I guess one of the challenges is also that it needs to be doable. I mean live, it's not something that you ask when ordering your auto subscription and then you have it and that's it. It's something at some point you might want to install an additional application and it needs to integrate with the the ones that are already there and that you're already using, right?

Julien Castiaux: 8:57

Yeah, exactly. Because like the, the business. So we focus like a small enterprise companies and then if they like Odoo, they continue using odoo as they grow. Okay? But as they grow, new needs will show up and they will need Oh yeah, yesterday didn't need that application and now I need it and I need to, to be able to install it in an easy way. You understand? Because if you have to shut down your server like for one week to do a migration or I don't know. Yeah. And that's annoying for the customers. So our job is also to make sure that integrating new stuff should be a seamless experience.

Olivier Colson: 9:34

And it might, it might seem a little, I don't know, stupid for, for people not knowing at all about all the technical thing behind this. Because when you install an application on your phone, it works like seamlessly, but uh, there is a huge work behind it to make it work. And that's basically what you're doing at Odoo.

Julien Castiaux: 9:48

Yeah, that's basically the hot job in our team.

Olivier Colson: 9:51

Uh, so about the way it's done now, this kind of very complex configurable thingy you need to do. How is it typically done in this industry? What were the available choices for the implementation, and which is the one Odoo went for?

Julien Castiaux: 10:06

Yeah. Okay. So the software that Odoo is, is called in the by the Academy as a highly configurable software. So highly configurable software also called a software prOdooction line is you have one software, one like generic software that you can customize depending the needs of like the customers or the user in general. Okay. An example of a highly configurable system that I guess most of our audience will know is the Linux kernel. Okay. Okay. So yeah, that's a bit over the top of Odoo, but I'm doing it.

Olivier Colson: 10:39

I mean it's very different, but it's interesting.

Julien Castiaux: 10:41

But I'm doing it. Okay. Okay. The Linux kernel supports thousands of different processor architectures. Okay. So you have AMD, you have Intel, you have PowerPC, etcetera, etcetera, etcetera. But you cannot like have like one compiled kernel that works with all of them. You just have one CPU in your, your hardware. So you should just have like.

Olivier Colson: 11:02

Because each architecture needs to be addressed by something specific to this architecture.

Julien Castiaux: 11:06

Yeah, exactly. So inside of the Linux kernel, in the source code, they have like many different implementations depending on like the architecture you are going to use. Okay? So you have, you have code that is enabled when you are using Amd64, you have other code that is used when you're using.

Olivier Colson: 11:25

What does it look.

Julien Castiaux: 11:26

Like if def all over the source code? Okay. So if there is a macro in, in C and so when you compile the Linux kernel, you do it by yourself, you just don't load one compiled already. But if you compile your nixternal, you have to provide a lot of compilation macro and just to say, Oh yeah, I want this configuration, I want this configuration for my processor, I want this configuration for my network network card. Et cetera. Et cetera. Et cetera. And then inside of the source code, maybe you have, like, a function that needs to to behave differently in case you have this architecture or another one. Okay. You have a if def if def my macro. So if def aim the 64, then some code is enabled. Okay. Will be injected in the final source code and some other is disabled.

Olivier Colson: 12:13

And so it's directly spread into the whole code code base or what. Okay. So yeah, so you have one function. If if if if if, if and.

Julien Castiaux: 12:20

Yeah it's not. If not it's not like. If else. If else. If else. If but if if.

Olivier Colson: 12:24

Def in the same.

Julien Castiaux: 12:25

Okay but it's it's basically the the same. So you have like the so they call it a filter and you have this filter is scattered all around the source code because you have like this function needs to be modified when you have like this for 64. Another function needs to do to be modified too. And so when you you look up the ifdef itself, wherever it's used, you have like hundreds of of of grep find and.

Olivier Colson: 12:50

How do they keep control of that. Because it makes the code pretty heavy I guess.

Julien Castiaux: 12:54

Yeah. It's pretty heavy and they call it the variability. Okay. As far as I understand it. Okay. And so there, there are a lot, a lot of academic study on it. So on the variability itself. But because it's not typical to the Linux kernel, a bunch of software are using this approach. So macros and like it's hard to understand, it's hard for developers to, to develop and maintain it because you have to, to keep track of all the places, all the places you have to modify to support like some features and whatnot. Okay. And so one feature is spread across a lot of file, and inside one file you have like maybe multiple features that are enabled or disabled. Okay? So that's, that's very complicated and that's the usual way I would say by the academic paper I read, it's about 50% of all software that are using all are highly configurable software that are using this approach. Uh, another approach that, uh, that have been studied for for some time is aspect programming. Okay. That was done in the Java cryptic name. Yeah, that's a very quick tip name for something very cryptic to okay. I had a lot of trouble understanding it and it was like, come on in the Java world for some time. It's not that much used nowadays, as far as I understand the thing. Okay, okay. Okay. So you have a you have your functions. Okay. Classical function and classical classes with methods. Attributes. Okay. Classic. Uh, typical. Yeah. Typical Java stuff. Okay. And with aspect programming, you can add like a bunch of, um, hooks. You can say, Oh, yeah. So I have my method and I want to like the classical method, like the common one. Okay? And when you have, when you want to enable one extra feature, you just plug into the, the many methods that exist and you say, yeah, before that this method one that the generic method, I want to run this code. After or in between or instead of. So that's the different, um, hooks you have and you can hook on, I guess, any method, but I'm not sure because I didn't studied it very well. Okay. And so from my point of view, a bit better than the, the Linux kernel. So you, you lose a bit of um, variability I will say because you cannot just modify like each line of code in every function, okay? So you have to make sure that there are enough hooks and by hooks I mean methods.

Olivier Colson: 15:28

So this might also mean that you need to sometimes refactor the very deep things to add new hooks.

Julien Castiaux: 15:34

Yeah, to add new hooks. Okay. And then when you have your hooks, then you can do your feature, but then you do your old feature inside one or a few files that are like next to each other in the source code. Okay, So that's, that's better because like, the features, they are grouped together and it's not that much scattered in the source code. Yeah. You have your hooks so you have to scatter the hooks, but that's fine. You can understand it. As a software developer, it's just basically just coding method, so it's fine. But the the problem with this approach, as far as I understood it, okay, is that the you don't have this kind of dependencies between your different aspects. So like a feature in aspect programming is called an aspect that's the name of it. And you don't have like dependencies between your many aspects. So it's difficult to say, Yeah, I'm going to want this aspect first before that one. And this is something we didn't understand well, this doesn't seem like a good fit for what we needed to do for our customers. So yeah, no aspect programming in Odoo.

Olivier Colson: 16:41

So you, you would need like to, to, to force some kind of sequence on the, the, the, the way the function calls are called. But that would mean defining constants and, and, and making sure that they don't overlap and yeah.

Julien Castiaux: 16:53

Something like that and you become very fast because you know we have like we have hundreds of applications so if we have to hundreds of sequence, it's going to be very hard time.

Olivier Colson: 17:06

Okay. Uh, another thing that you're not mentioning and I think it's worth telling why it's not a good idea is inheritance. Because actually, one might just say, okay, but, uh, if I have my accounting module, which needs to do something on the customers or on the partner model, and I want to add some behavior in the accounting module, well, let's just override or extend the rest partner model and, and put my thing in the functions there. And it will work from a very, very distant and abstract point of view. It makes a little bit of sense. Yeah, sure. Isn't it a good idea? Yeah.

Julien Castiaux: 17:38

So actually, that's so that's the very academic way to, to do it. So that's the thing.

Olivier Colson: 17:43

A student would think about like immediately and then realize that it's not a good idea.

Julien Castiaux: 17:47

Yeah, but he has to. He will not realize it's not a good idea at first because at first it works. Okay. So imagine you have your, your partner in the, the, the common framework. Okay? Like let's call it the base partner. Okay. So you have a name, an email address and an address, physical address. Okay. And then you have to inside of your CRM application, you have to add a bunch of new stuff on like the the partner. So that's easy. You just create a CRM partner that inherits from base partner and that's it. And you have to two fields a method, etcetera. And then you say, Yeah, but inside my application I'll also need to add a bunch of stuff or modify a bunch of stuff. So to you create sales partner. Okay. And then you are in the stock application and the stock application just needs to work with a partner, whatever the partner is.

Olivier Colson: 18:38

Okay. Which one do you use?

Julien Castiaux: 18:39

Well, which one do you use? Should you use the base partner, the CRM partner, the sale partner, or even worse, the CRM sale partner?

Olivier Colson: 18:46

Yeah, because you would need like something that is also mixing them.

Julien Castiaux: 18:49

Yeah. Mixing them because there is no guarantee that the modules are working alone. Yeah. You stand stock so you can install like the two other modules too.

Olivier Colson: 18:57

And you're stuck.

Julien Castiaux: 18:58

Yeah, you're stuck. And. But what's the stupid idea? The stupid solution about it.

Olivier Colson: 19:03

Tell me.

Julien Castiaux: 19:04

The stupid solution to it. Wouldn't it be nice like for the stock application just to know what class should should it instantiate or work with.

Olivier Colson: 19:13

Magically?

Julien Castiaux: 19:14

Magically, Yeah.

Olivier Colson: 19:15

You just would ask it. Uh, could you give me just a partner?

Julien Castiaux: 19:18

Yeah, it gives me a partner. It is. Whatever it is. Okay. And we did. We didn't know it was stupid, so we did it. And it works.

Olivier Colson: 19:26

Okay. So that's what it would do is doing.

Julien Castiaux: 19:28

Yeah, that's what I would do is doing so but clearly at one time before like the application once. Okay, so we have a, a bit of uh, setup, uh, phase that we call like the registry installation, I think. Is that another name? But it's not. Um, so when you're.

Olivier Colson: 19:44

Starting the server. Things going on.

Julien Castiaux: 19:47

Something going on, the first phase is to discover all the classes. Okay, So base partner, CRM partner, sales partner. That's it. Okay. And then you see what are the applications that are in. Stalled. Okay, Let's say like both sales and CRM are installed. Okay, so you take the two classes, sales partner and CRM partner. Okay. You say I'm going to use those two. One and you create a new class at one time. Okay. You call it partner. Whatever partner is, you know? Okay. You call it just partner and you make it inherit in the correct order. The correct order, given the dependencies between applications. Okay. In the correct order to the partner classes. And so when you are in stock, you don't like import like the real classes from the source code, you just use that class that was created at one time and you use it okay.

Olivier Colson: 20:39

And it's really nice because for you it's transparent. You have the impression that you're using just one class, but that class actually, well, if you just read the code, it doesn't exist.

Julien Castiaux: 20:47

Yeah, it doesn't exist. It's a class that was created.

Olivier Colson: 20:50

At one time.

Julien Castiaux: 20:50

At one time. Okay. And everyone who had like a few knowledge of like how you should do like object oriented programming will say that's, that's heresy. That's, you know, you cannot do that. Okay. But we didn't know. We cannot do that. So we did it anyway. And it works. It works super well actually. Okay. So really decided decided to, to create classes at one time that will inherit from like all the classes that are actually in use. So you have like, like the whole application can can use. It's working very, very effectively. So I think that's the single thing that made odoo what it is today. Okay.

Olivier Colson: 21:34

Yeah. I guess it, it allowed everything actually, because when you have all those apps mixing together, if we, if you don't have such magic thing to allow that it's just not possible or you would need to go for something really weird where you actually instantiate things into the database and so on.

Julien Castiaux: 21:51

But no, no, no, you, you will, you will use an older approach, maybe. I don't know because I'm not an expert of them, but maybe you can work your way with like dependency injection or I don't know, but you can think of another architecture and I'm sure.

Olivier Colson: 22:07

That you will need some kind of very good idea like that that is kind of breaking the rules to make it a bit more automatic and not handle everything by hand.

Julien Castiaux: 22:16

Yeah. So, you know, I've been working with this architecture for five years now, so it's the one I know and I've never seen the other like highly configurable software that I studied. Like they had like other approaches and we didn't like them because we, we felt like it's too complicated and we cannot do like, all the things we want we want to do.

Olivier Colson: 22:37

Okay. Okay. And, um, how would you call this kind of inheritance? So if. If it's inheritance, if you want to call it inheritance.

Julien Castiaux: 22:44

So, yeah, let's put it this way. Let's call classes like the regular classes that you inherit, okay? Like, out of place. So you have your animal and you create a dog and that's inheritance out of place. You know, you have like two different classes, just one inheriting from the other at Odoo. Like the this approach to have like classes at one time that inherit from the other. This is all like technical solution to make inheritance by extensions. So imagine you have like your base partner and you add stuff inside the base partner. It's not really inside the base partner. It's inside the like the one class, the the one time class. But let's think it this way. And so you have your class and we are going to inject new stuff into that that class. Okay. This is in place inheritance in in in a way. Okay. And we call those classes models. Okay. So that's a common word in Odoo. So you're not going to talk about like the partner class, you're going to talk about the partner model. So you do the the separation between like classes, regular classes. I assure you, we continue to use regular classes when they apply. Okay. And you use also models. Okay. And the models are like the those like one time. One time classes.

Olivier Colson: 23:59

Okay. So you actually get all the advantages of object oriented programming. And from a pure development point of view as well, as long as you have understood that there was this this magic runtime class that was getting everything, it's super convenient because it doesn't change much actually. Yeah.

Julien Castiaux: 24:14

And also the way like the developer use it, they don't overthink it. So do you just have a class and you inherit it or keyword is inherits? It should be extend. But like in Java they they choose extend to do inherit. So it's it's it's fair. It's fair. It's fair. Okay. And so you can like so extend your, your classes and like the, the way like developers do it, they don't overthink it. They don't think about model, they don't think about the runtime class, they just do it and it feels natural to them. So that's something we achieved and we are quite proud of it. We made something that is not too much different from what developers are used to, so they continue to use classes they continue to use like. The returns, even if it's not inheritance out of place under the hood. They they are quite capable of doing like, application in an efficient way.

Olivier Colson: 25:07

Yeah. You get into it pretty, pretty easily. Could you tell us a bit more about what's above it? So you were talking about the modules a little bit and dependencies between modules. So how does it work exactly?

Julien Castiaux: 25:18

So every application comes with a manifest and inside of the manifest you can like declare like the name of your application, the description, but also like on what other application you depend on.

Olivier Colson: 25:30

Just to be clear, you're talking about applications. Application and modules are the same. We we tend to use both words to say the same. Yeah.

Julien Castiaux: 25:35

Yeah.

Olivier Colson: 25:35

So now you know. Okay. Yeah. So applications, let's go for application.

Julien Castiaux: 25:39

The, the module is like the technical term and like the application is the word we use for like customers say, oh you have your application actually somewhere in some module technical name. But okay, so we tell.

Olivier Colson: 25:50

It application if you want. Okay.

Julien Castiaux: 25:52

So that makes the, the two a bit. So that's okay.

Olivier Colson: 25:55

Everybody does here.

Julien Castiaux: 25:56

Okay so inside your, your modules or application, you have your manifest inside the manifest you can declare like dependencies on other modules applications. Okay. That's the like the usual way. So you just imagine you have an NPM package and you say, Oh yeah, I depend on this other package. Basically it's the same. And let's take CRM. Crm depends on mail, okay? And mail depends on web, and web depends on base. I think in that order. Okay. On bus there is also bus in between. Okay, so you have this classical like dependency thing and like the classes are going to like put in the correct order, pendency wise between application. That's okay. And we also have like a reverse dependency way. So when you install sales next to CRM, you maybe you have to like bridge the two together to do this integration thing. I was talking in the beginning, okay. And wouldn't it be nice if when both like CRM and sales are installed together, then you have like a new application, like a bridge application that is automatically installed and can that can add like all the bringing code between the two classes.

Olivier Colson: 27:06

So for example, we have that with uh, stock and account module, and you have the stock account module just next to it that is bridging them both, and it's installed by default. So it's not something you need to go and install yourself. It's, it's there if you install both. Yeah.

Julien Castiaux: 27:18

Because when you just have like stock itself alone, it needs to work alone. Okay. So it doesn't need to do like anything related to sale. But then when you have sale and stock together, whenever you sell something, you want it reduced from your stock logic. Okay. The two application, they are working alone, isolated independently. But when you install the two together, we have this reverse dependency thing. We call it auto-install and we auto-install like the stock module. Okay, that's the name of the module. And basically it just that is all the, the classes, all the overrides needed to bridge the two together. So when you do a sales, you have the, the override that kicks in, and you remove it from the stock.

Olivier Colson: 28:03

And what happens into the database then because we talked a lot about the classes and the way the software really will interact. So that's cool but anyone knowing a little bit about this kind of application will tell you, okay but then I need to have data to manipulate.

Julien Castiaux: 28:19

Yeah sure, sure.

Olivier Colson: 28:20

How do I store them? How does it.

Julien Castiaux: 28:22

Work? Actually, it's easier to think from the database point of view then from like the classes point of view. Okay, so, uh, every model inside of Odoo is actually one table in Postgres. Okay? One model equals one table. Okay.

Olivier Colson: 28:39

Automatically.

Julien Castiaux: 28:40

Automatically. Okay. Okay. And, uh, for like. And you have like, more classes for like relations. So when you have like many to many relation. Yeah. You have like the extra class table inside, um, Postgres for, to do like the join between the two tables. And when you install a new module, it's super easy, you install a new module, you have a bunch of new fields that come, but we just alter the table. That's it. Okay. It's super from the database point of view is super easy. So you insert a new module or it comes with its own overrides, new extension of uh, classes etcetera. And an extension of the classes like a model is a table. So when you do extend it, you just add stuff to, to the table, to the table at a table.

Olivier Colson: 29:23

That's it. Yeah, I think it's good also because, uh, since it's really close to the, the python objects that you're using, it's also super easy to, to get into because, well, uh, as long as, you know, the objects, you know, the database.

Julien Castiaux: 29:36

Uh, basically, yeah. So. So they have the, the same name just like we use dotted path in, in Python and we have like underscore path in, in Postgres. So once you know that you can like do your fire up like SQL, do your queries to introspect the database and you wouldn't be surprised by anything. You just you have your fields. Yeah. And you have your columns. That's it. And you have your data. And the two, like, really look like each other. So there is no magic. There is no like, I know, like some software like you are using, like trying to implement like inheritance right at the database. And so it's quite hairy, quite fast. We don't do that. So we just have like basic tables. I will dare say that we could use like any database engine to do it. We don't use anything specific to, to Postgres, like maybe 1 or 2 things that we will need to, to convert every time you need to, to convert to a new database, but mostly standard SQL, Basic SQL.

Olivier Colson: 30:36

Yeah. The philosophy is really to have something as simple as possible because when it's simple like that, it's more powerful because it's more modular.

Julien Castiaux: 30:43

Yeah, it's, uh, it's not our decision to make it super easy, but it was possible to make it super easy. So we keep it. We try to, to keep it this, this way.

Olivier Colson: 30:52

Okay, so we talked a lot about the, model and the way it works and it interacts with persistency and at runtime. But in a typical architecture, you normally also have view and control. What do we have about that?

Julien Castiaux: 31:05

So that's a good it's a good question. So we talk about the model, Okay, that's the models classes. It's also like the the model part of the MVC architecture. So we are using like kind of an MVC architecture. So we have like obviously models data, okay? We also have controllers. That's all the Http part and that's my part. Okay. At work. Okay.

Olivier Colson: 31:26

And we also tell us about it. Okay.

Julien Castiaux: 31:28

So I think like the, the model by itself, it's cool, but like customers are not going like to write SQL queries or to white code. Yeah. Really? So they, they need, uh, an interface to the outer world. Okay. This interface, like in MVC is the controller, okay. And our controller is just like http routes easy so you can get post put etcetera. Easy. You have your, your routes so you can say, okay, so I'm defining a function that will be called whenever I access this URL, you know, okay, maybe it's web login, you access web login or you have a function that is executed. Okay, those are the controllers. And likewise with models, we also use like this approach of having like one class when you have like all your, your routes endpoints, we call them defined, okay? And you can extend it in new models so you can replace the endpoints, uh, in a wheat form them etcetera. The same way like models work. It just, it's a different registry, the registry for them to like the, the place where like all the, the, the one time class is belong. So there is one registry for the models and there is one another. Controllers for the controllers. Okay. And uh, the, the inheritance mechanic is a bit different because like, we have much less controllers than we have models. So we could have, like, a simpler solution, actually, like using the inheritance of Python. Yeah, it's cool. It's. Somewhat easy. Okay. Okay. And we also have like different apcs layers, so you don't have to define you are not obliged to define your own controller to access your data. There are like a bunch of generic controllers that exist. We call them RPC and you can just ask for them like your web client to access like, oh yeah, I want to, to search for all like the partner that begins with Bob and you can do it. You don't have to write your custom controller for it. Yeah there are few like RPC endpoints uh, to do that in different um, format of data. So we support xml-rpc so people that don't like Xml-rpc because it has XML in the name, but usually a library so you don't have to serialize deserialize the XML yourself. You just, you it's like you call a function in your source code and under the hood it does like call to the server serialize, the data or your arguments to the function and, and they serialize back like the answer.

Olivier Colson: 33:55

Yeah. So it's good you don't have to mind about the.

Julien Castiaux: 33:58

Yeah. You don't have to mind about the XML part of XML you know. And you also have Json RPC because like people do mind about the XML part of inside RPC. So they, they were the Json because like yeah, Json is better. Yeah. Okay. So they can serialize the data themselves. They like to sell the data themself and our web client, our own web client. So JavaScript framework is also using like the XML, json RPC. Sorry.

Olivier Colson: 34:24

Okay. Uh, about the views now, is there anything special?

Julien Castiaux: 34:27

Yeah. So about the views. So obviously when you have like just your, your application, you are going to have like a sale order, classic sale order. Okay. And you show a bunch of stuff on your sale order, but when you install like the stock application, maybe you need to have like a bit more stuff about it. Maybe you not stock, but the deliveries application. Maybe you ought to have a button on your sale order on which you can click to see. Oh yeah. So I sell that and I want to, to see where it is, uh, when it's going to be shipped to the customer. Okay. So you want to, to modify the, the view?

Olivier Colson: 35:03

Yeah. Because you're adding new fields, new behaviors, so you might want to see them in the views. Yeah.

Julien Castiaux: 35:07

You want to see them in the view. Exactly. Exactly. And so you, you can change the view. And so we also have this kind of, uh, inheritance, uh, in place, out of place, uh, mechanism. So you can define so you have your base, your, your view, you define it. It's a XML file because why not? Yeah.

Olivier Colson: 35:26

Uh, just just to, to, to, to be sure everybody gets it. Uh, when you define a view in odoo, we have a dedicated syntax for that. And basically it's, it's, it's done for you. You're not writing all the HTML, CSS and.

Julien Castiaux: 35:39

No, no, you don't. You, you're just like, Yeah, basically you just say, oh yeah, I want a sheet we call it. So it's a view plane on your, your screen. Okay. Okay. And you're going to say, Yeah, I want to have this field, this field, this field shown on this sheet. And maybe you want to add another sheet that will be in another tab on screen. Okay? And you have like other fields that are shown, maybe the relations. Uh, okay, that's it. So you just define your, your fields. It's basic. So you don't worry, you don't have to write your section in HTML, your articles, your P-balise.

Olivier Colson: 36:12

So you have means to control what is where. But basically it's done for you. Yeah, it's.

Julien Castiaux: 36:17

Done. It's done for you. And basically you have like a minimal control out of it because we want like the whole application look the same. So that's the, that's the part of the JavaScript, uh, team to, to make it look good. We define them in, in XML file because why not. Or we, we need to do an syntax that is close to HTML, but that is not HTML, but it's close to HTML. But that is not HTML. So we use XML. Why not? With XML there is uh, the xpath that come that's handy for like the inheritance. So we can say yeah. Okay. So my sheet with my fields and you install a new application, you want to add your. So you added a field in your model. So it's an extension and you want to show that field on the The View. But you can write an extension view and say, yeah, okay, I'm going to to write a XPath. So I want to modify this tag and to add like maybe one new tag, one new field attribute. Okay. And we have the, the same mechanism of uh, like inheritance in place and also out of place. Uh, sometimes you don't, you just want to have like a template and to copy out of place this template for your needs. Sometime you want to modify in place a view and that's, that depends on the application, that depends on the needs, the business need.

Olivier Colson: 37:31

And so, so basically it's working just like in the, the, the Python counterpart and at runtime, the view is generated with everything that needs to be there because it sees that there is an inheritance and we are adding some field next to another one, this kind of thing and just takes everything, computes it and gets it.

Julien Castiaux: 37:45

Yeah, that's it. And that's the reason we don't use any other technology. There is nothing wrong with like all the others technology. But. Just they don't have this idea of models. Should I say. So whenever we try to use like other technology and plug them into Odoo, like we tried with Jinja for some time, quickly, we we reached the limitation, not the limitation of like the framework themselves. They are very they're very fine, very working very well. But the limitation otherwise about them like we couldn't like do the thing we wanted to do with those libraries. And so at some point we basically we just made on our own and, and since then we, we maintain that.

Olivier Colson: 38:31

Okay. And it allows for more flexibility indeed. Plus the good thing with the views and with the way they are they are working is also that I mean, as a user, you can go into the menus, create your own from the interface, your own inherited view, type the code. So you still need to type a bit of code. There is studio as well, there is studio as well actually. You don't need to type code. Yeah. It's I'm type code. Yeah. So you could even use the UI to do that. But it will generate an inherited view and behind the scenes you will do exactly what a developer would have done. But just with the UI and we're in a, in a way easier manner actually. And it's also because there is this model working like this that.

Julien Castiaux: 39:06

Yeah, there's this model working like this and that's something we forgot to say because we have like this registry at one time. We can like modify it also at one time. So the registry of models, the views, the controllers, you can play with them at one time. So we talked about like the studio application, but you don't need studio. You can like go to the technical menus of odoo on the web page and, and modify the views or create new ones. You can do it because it's possible and it's easy at some point we just made an application studio that do it a friendly way for the customers so they can like install the studio and they can like. Yeah. And I mean edit everything on.

Olivier Colson: 39:44

There totally makes sense for, for this kind of easy customization where you just need to add the field somewhere because, uh, is it worth it to pay a developer for these kind of things? Well, not really. Yeah, not really. You don't want to do an application if you just need one field, uh, one extra field, you just. You install studio. You, you add the field and done. That's it. Okay. But when it gets more complicated, then yeah, better have like, real developers like, maintaining a software. Sure, sure. When there's more logic involved, you need that. Yeah, sure. Yeah. Good for us. Are there now additional things that we didn't mention about the ORM and the Python framework that you would like to talk about a little bit?

Julien Castiaux: 40:18

Yeah, there is this complicated thing because as we we the wheel kind of. Yeah, we, we have to be humble about it. So there are like a lot of good ideas, good stuff out there. And because we are like we doing it our own way, we have to make sure that everything is up to the latest standards, etcetera. We have a very few like hard dependencies, like Python dependencies framework-wise. So we have Postgres of course. So we are using like Psycopg2, that's the driver for the database for Python. Okay. We didn't write our own. Okay, sure. But the we, we wrote our own, so we have to maintain it. We have to make sure it's up to the latest standard. We have to make sure that there is no breach, security breach. I mean, to make sure that everything is working. Also, like all like the backward compatibility, we have to make sure this is working because we are not like the only customers. We are not like the only developers that are using Odoo like people all around the world are using Odoo. So we are in this kind of weird position where we are like Django, should I say, like we are like the developers of the framework, but we are also like users of the framework. And so we have to make sure that it evolves the correct way, the way like we are to the Python framework. We, want to make it evolve, but we also need to make sure like all the customers like can like keep the pace and make adapt the code to be up to the latest standard. That's challenging actually that's that's really nice. Also like http wise we also at some point we we didn't add ways to like stream files so whenever you were downloading a file like the one worker was stuck like downloading the file to the, to the customer, uploading the file to the customer since we have to, to change. And so we have this new thing. We can like stream now we can stream files, something new and there is all the time like new stuff to do. We can like study. So we, we studied the highly configurable software being done in for other software. So we, we learn stuff from there. Yeah.

Olivier Colson: 42:27

So that you can get ideas.

Julien Castiaux: 42:28

Yeah, we can get ideas.

Olivier Colson: 42:29

Copy something and be like, okay, this is a very good idea. Yeah.

Julien Castiaux: 42:32

And that's really the, the, the, you know, the open source spirit. So there are like good ideas everywhere. It's open source. And so you can like adapt them to your own needs, you can understand them. And also maybe we do nice stuff, cool stuff that we used in other applications. That's very fine about it. It's very nice to to be like open source, like all the community. Very nice.

Olivier Colson: 42:58

Well, thank you, Julien, for all your answers. I think you gave a lot of explanation on really the magic. Yeah, that was going on behind behind Odoo. And I think it's really interesting for people to know that because you don't realize that when you're using it. But actually all this is really complex and really well done. And I must say, one of the first things that really impressed me when I entered the odoo so it's been it's been a while. It's been six, six years, a bit more now was really all this mechanism with inheritance and extension actually to use the right word. It's, it's.

Julien Castiaux: 43:27

It's, it's bizarre at first, but you get used to it very fast.

Olivier Colson: 43:30

Yeah. And it's.

Julien Castiaux: 43:31

Too fast.

Olivier Colson: 43:32

It's really powerful and indeed it's something you look at it, you're like, okay, that's weird, but that's actually fun. Yeah, it's.

Julien Castiaux: 43:38

Yeah. So when, when you, you, you come out of school, you have been teaching a very specific way or you should do that and we don't do that. It works. It's, it's fun.

Olivier Colson: 43:50

So the final word could be, uh, think out of the box.

Julien Castiaux: 43:53

Yeah, think out of the box. That's. That's really what the other people like more senior people did at the time. They sort of out of the box. Yeah, we have a problem and they bring a solution. And now we continue working with it.

Olivier Colson: 44:06

Well, good luck with that.

Julien Castiaux: 44:08

Yeah, thank you very much.

Olivier Colson: 44:10

And that's a wrap for this episode. Thanks for joining us. I hope you enjoyed this discussion about the technology behind Odoo and its apps. If you'd like to stay for further insightful tech and dev discussions, I suggest you listen to our episode going deeper into the development of our accounting app. Until then, see you next time. Cheers.