DEV Community: Luong Xuan Trung Dung

Setup Odoo 19 and Postgres 15 with Docker

Luong Xuan Trung Dung — Thu, 30 Oct 2025 13:34:12 +0000

I'm writing this from the satisfaction of having a local Odoo instance with its isolated running environment in my Windows machine. Having looked up near and far, through searches, with multiple LLM models and 2 days of frustration, I finally did it.

I could have just installed Odoo's official Windows installer but there is a question of management. Besides, the installed Odoo from this method is packaged with Postgres 12, which is relatively old in my opinion.

I tried to set up Odoo from scratch by its Git repository since this is recommended to developers, but installing its required Python libraries always ended up in a variety of errors. In addition, my pre-installed Postgres 18 was conflicted with this Odoo due to CTYPE and COLLATION.

Thus, after removing everything from the previous attempts, I went for Docker and here is what I did.

Prerequisites

Docker Desktop version 4.18 or later.
Docker CLI, which is packaged with Docker Desktop. Make sure to add it to your machine's PATH environment variables.

Docker 101

It's useful to know some Docker terms before we continue:

Image: a read-only template that contains the application code, runtime, libraries and any other dependencies.
Container: a lightweight, isolated, and executable package running instance of an Image.
Volume: a persistent data stores for containers.
Bind mount: a way to link a specific file or directory on the host machine's filesystem directly into a Docker container.
Compose file: a simple YAML text file to manage the building of Docker Containers stack.

An example of a docker-compose.yaml:

services:
  web:
    build: .
    ports:
      - "8000:5000"
    develop:
      watch:
        - action: sync
          path: .
          target: /code
  redis:
    image: "redis:alpine"

The Docker Compose YAML

Like the example above, I declared the building of 2 containers, one for Odoo (version 19) and one for Postgres (version 15). Afterward, the containers are meant to run in the default ports (8069 for Odoo and 5432 for Postgres).

services:
  web:
    image: odoo:19
    depends_on:
      - db
    ports:
      - "8069:8069"
  db:
    image: postgres:15

The thing is when you delete a container, any data written to its writable layer is also deleted. Docker's volumes are meant for this, for storing data outside of the container's file system, on the host machine as a backup.

Now, with that in mind, I declared the volumes for the containers:

services:
  web:
    image: odoo:19
    depends_on:
      - db
    ports:
      - "8069:8069"
    volumes:
      - odoo: /var/lib/odoo
  db:
    image: postgres:15
    volumes:
      - postgres: /var/lib/postgresql/data

volumes:
  odoo:
  postgres:

As you might notice, in order to use Odoo with Postgres, we also need to declare environment variables. These include a database, a Postgres superadmin's username and password for Odoo's content management.

services:
  ...
  db:
    image: postgres:15
    environment:
      - POSTGRES_DB=postgres # Example DB name, don't use in production
      - POSTGRES_USER=odoo # Example username, don't use in production
      - POSTGRES_PASSWORD=oodo # Example password, don't use in production
    volumes:
      - postgres: /var/lib/postgresql/data
...

This superadmin account and database is automatically created in the built Postgres container. For Odoo to actually use it, remember to confirm them once more in the browser.

How it should look in your browser when the containers are running properly. Image from Cybrosys

The Odoo Development

Odoo development involves creating custom modules. Thus, the YAML above needs to be updated with bind mounts so that your modules can be copied (or mounted) into the containers.

services:
  web:
    image: odoo:19 # Choose your desired Odoo version
    depends_on:
      - db
    ports:
      - "8069:8069" # Maps host port 8069 to container port 8069
    volumes:
      - odoo: /var/lib/odoo
      - ./config: /etc/odoo # For Odoo configuration file
      - ./addons: /mnt/extra-addons # For custom modules

This means, in the directory of the Docker Compose YAML file, there should be 2 folders, config (for custom Odoo config) and addons (for your custom modules).

Now, as you want to deploy your modules to the local Odoo application, the easiest method is to remove the Odoo container (just the container, not its volume data), then restart it to trigger the bind mount. This is irritating but I found no other way.

Here are the Docker commands that I used, which web is the declared Odoo container in the YAML file:

docker compose down web: remove the container
docker compose up -d --no-deps web: restart the container

or this combine command: docker compose up -d --no-deps --force-recreate web

Final thought

After the setup was done, I happily went on through the Odoo tutorial to learn about its server framework just to face another source of frustration since I could not set up the container's Python environment in my code editor and I could not quite understand that document. Anyways, maybe at some point, I'll be writing about this.

Nonetheless, I managed to finish that as well with the result is a functioning custom module that also serves as a demo for this article.

I hope you enjoy this tutorial. Let me know if you have any questions by: Github, LinkedIn or Email.

Thank you for your time.

Simple internationalization using React Context

Luong Xuan Trung Dung — Sun, 24 Aug 2025 04:01:35 +0000

The age of globalization has opened the door for a diverse range of internet content, especially for those that is not English. This creates a trend where websites become adaptible to multiple languages, serving appropriate contents according to user's preferences. These websites are known to have been internationalized.

In my research of making such sites in React, a popular framework for web development, I have followed many tutorials of many existing libraries to implement the features, yet failed to make the site serving the correct content. This frustrated me, since I think internationalization should accomplish something as simple as a change of text. Thus, I have to change my perspective, by looking at the foundation of those libraries, which is React's Context.

Prerequisites

Below are what I think you should have known before continuing with this document:

Basic understanding of React, more specifically: Function component, component's props, state and effect
Javascript's ES6 syntax and JSON file format.
An IDE, a software that supports your coding.

If you are confident with the knowledge above, feel free to take a look at this demo for reference. Or, you can create a sample React app repository to follow along, using these commands in a folder opened in your chosen IDE:

For NPM users: npx create-react-app
For Yarn users: yarn create react-app

The content JSON files

These files are what I used to store translatable texts, any piece of content that can be switched between languages. Here is the English content of the demo, which I named en.json:

{
    "en": "English",
    "vi": "Vietnamese",
    "edit": "Edit",
    "saveToReload": "and save to reload",
    "learnReact": "Learn React"
}

Indeed, the texts above come from the generated React repository. I simply translate those to my native language Vietnamese and create a new file, named vi.json. Remember, it's important to standardize these content files. They should always have the same keys but different values.

Using those content files in a context is a bit tricky, since you would need to import the files asynchronously, read and return them.

const dictionaries = {
  en: () => import("../contents/en.json").then((module) => module.default),
  vi: () => import("../contents/vi.json").then((module) => module.default),
};

const getDictionary = async (locale) => dictionaries[locale]?.() ?? dictionaries.en();

The constant dictionaries stands for the collection of read JSON contents.
The function getDictionary is how we would get the correct content for usage in the context.

The context and its provider

React's context is a convinient method to manage states that are meant to be used in multiple components. In the demo, these values would be:

locale: the current language of the website, should be either 'en' or 'vi' for the sake of simplicity.
setLocale: the method to set the website to another language, its only parameter.
dictionary: the content corresponding to the current language.

Here is how the context is defined with those values:

const LocaleContext = createContext({
    locale: defaultLocale,
    setLocale: (lang) => { },
    dictionary: {},
});

In order to used that context in any component, a provider must be defined. It's a wrapper component that takes the children props, which means it would be the parent of other components within the same tree. Because of this, we turn those values into states that can affect the children or wrapped components.

function LocaleProvider({ children }) {
    const [lang, setLang] = useState(defaultLocale);
    const [dictionary, setDictionary] = useState({});

    useEffect(() => {
        (async () => {
            const json = await getDictionary(lang);
            setDictionary(json);
        })()
    }, [lang]);

    return (
        <LocaleContext.Provider value={{ locale: lang, setLocale: setLang, dictionary: dictionary }}>
            {children}
        </LocaleContext.Provider>
    )
}

As you can see, the hook useEffect is for listening to the changes of the state that I named lang. So, whenever lang is set to a different value, a nameless async function would be called to get the content corresponding to that lang. This is how the website's content is served.

After all definitions are done, the context can now be used in React's main component by wrapping other components:

function App() {
  return (
    <div className="App">
      <header className="App-header">
        <LocaleProvider>
          <img src={logo} className="App-logo" alt="logo" />
          <AppContent />
        </LocaleProvider>
      </header>
    </div>
  );
}

How to use context and change its states

The common usage of the mentioned context is displaying content. Here is how it's done in the component named AppContent, which is wrapped by the context provider. In a sense, it would be similar to destructuring an object:

function AppContent() {
    const { dictionary } = useContext(LocaleContext)
    return (
        <div>
            <p>{dictionary.edit} <code>src/App.js</code> {dictionary.saveToReload}.</p>
            <div style={{ display: "flex", justifyItems: 'center', alignItems: 'center' }}>
                <a
                    className="App-link"
                    href="https://reactjs.org"
                    target="_blank"
                    rel="noopener noreferrer"
                    style={{marginRight: 20}}
                >
                    {dictionary.learnReact}</a>
                <LocaleSwitcher />
            </div>
        </div>
    )
}

You might have noticed another component that is named LocaleSwitcher. This one is a simple switch to control the current language of the website, using the defined state setter named setLocale:

function LocaleSwitcher() {
    const { dictionary, setLocale } = useContext(LocaleContext)
    const switchLanguage = (value) => {
        if (['en', 'vi'].includes(value)) {
            setLocale(value)
        } else {
            setLocale(defaultLocale)
        }
    }

    return (
        <select defaultValue={defaultLocale} onChange={(event) => switchLanguage(event.target.value)}>
            <option value="en">{dictionary.en}</option>
            <option value="vi">{dictionary.vi}</option>
        </select>
    )
}

Basically, it's a select tag with a handle for when its option is selected. The option's values should match the acceptable values of the locale state, as the handler function switchLanguage would set that state to any of those. So by selecting any of those options, you should be able to change the content in the demo.

Everything in Typescript

Personally, I prefer Typescript to Javascript because of type safety. A mishandling value would result in the application ended up in layers of exception. Besides, who doesn't want to have a clear vision on the inputs and outputs of their system? Well, that is if you can handle the nuisance of having to define types in almost every piece of code.

Let's begin with the types (and interfaces, which are object types) used with the context states:

type Locale = 'en' | 'vi'
type Dictionary = Awaited<ReturnType<typeof getDictionary>>
interface ILanguageContext {
    locale: Locale;
    setLocale: (newLang: Locale) => void;
    dictionary: Dictionary;
}

As you can see, the Locale type represents all supporting languages in the demo. The Dictionary one stands for the type of the read JSON content files, which is an object type with clear defined keys. Finally, the context's interface to combine those 2 types. Here is how the types are used in context, under the Typescript syntax that is called generic:

const LanguageContext = createContext<ILanguageContext>({ locale: 'en', setLocale: (lang) => { }, contents: {} });
function LanguageProvider({ children }: PropsWithChildren) {
    const [lang, setLang] = useState<Locale>('en');
    const [dictionary, setDictionary] = useState<Dictionary>({});

    useEffect(() => {
        (async () => {
            const json = await getDictionary(lang);
            setDictionary(json);
        })()
    }, [lang]);

    return (
        <LanguageContext.Provider value={{ locale: lang, setLocale: setLang, contents: dictionary }}>
            {children}
        </LanguageContext.Provider>
    )
}

Other than above changes, nothing else really need to change in the demo's main code.

Final thought

I admit that internationalization is more than just changing texts. There are things like time zone(s), currency, number format that need to be changed, as well, and they are based on location, not selected language.

The demo, at the moment, fails to detect that as I hard-coded the default language to be English ('en') without taking into account of the user's location.

Another disadvantage of this text-change context is its dependence to static files, the JSON ones. Thus, a roburst website with dynamic content would require a CMS (content management system) to handle its content.

The context in the demo should be usable in the React ecology, meaning all React-based frameworks. I used an instance of it in my NextJS project since all I need is a simple text change.

I hope you enjoy this tutorial. Let me know if you have any questions by: Github, LinkedIn or Email.

Thank you for your time.

Trackable Flask API using EventSource

Luong Xuan Trung Dung — Sat, 16 Aug 2025 10:45:20 +0000

Setup

APIs are connections between computers to exchange information or data. For a website, we expect them to return a visual change, something as simple as a now different text or a floating message in the corner of the screen.

However, what if the API we are waiting for is taking too long to respond to us? Are we supposed to stare at the screen now? Is there anything else we can do on the website at the moment? Such frustration and panic would ruin the experience of any patient user. And to us developers, the general solution is an API that would return its progress periodically.

In this tutorial, I’m going to introduce an answer to the above issue, by using EventSource class along with a Flask API server. The complete demo is available here for reference

Below are the prerequisites for the demo as mentioned in its README, please make sure they are installed properly before you continue:

An IDE for a comfortable coding experience, either Visual Studio Code or PyCharm.
Pyenv, a simple Python version manager. For Windows users, you should use the recommended pyenv-win.
Python, the programming language used in Flask. This tutorial is meant for version 3 or later.

The Flask server

Virtual environment

Flask is a lightweight Python web application framework that can be used to easily and quickly set up an API server. To set it up, we would need to make a Python virtual environment. This is crucial to prevent potential conflicts with other Python projects in your machine.

If you have properly installed Pyenv, you should be able to run the following command in a desired location:

In Mac OS and Linux: <pyenv> /versions/3.11.11/bin/python -m venv .venv
In Windows: <pyenv> /pyenv-win/versions/3.11.11/bin/python -m venv .venv

Whereas <pyenv> stands for where you have installed the tool in your machine.

Once the command is done, there should be a hidden folder .venv in your chosen location. Any Python 3 version should be fine for this tutorial, so you can replace 3.11.11 in the above command with any desirable version.

The next step is to activate the installed environment, by using this command:

In Mac OS and Linux: source <location>/.venv/bin/activate
In Windows: source <location>/.venv/Scripts/activate

Whereas <location> is where you install the environment. The successful activated environment would be indicated by the prefix (.venv) in your IDE's terminal.

In case you activate the wrong environment, you can leave it by a simpler command: deactivate. Otherwise, you should continue with installing Flask: pip install flask

The session APIs

We only need 3 APIs for the demo:

GET /generate: generate strings from 2 arguments: amount and length. It is meant to be trackable.
POST /session: set up session values.
GET /: Render a simple web page from the templates folder, as well as setting default session values.

Here is the API to return the index page and getting sessions:

The index page from the server is rendered in your browser similar to any HTML file, except that it has been put through Jinja2, Flask’s default template engine, to assemble it with session values before returning to the browser:

Sessions are values that persist in system memory as long as the server can run, which can be used between APIs. In this tutorial, they determine which set of characters should be used in the string generation API.

Here is the API to set session values, received from the client and return an HTTP response:

The values are chosen to be numerical for better communication between the client side (Javascript) and the server side (Python), since numbers are the same between 2 languages.

The Javascript/JQuery client

The rendered index page consists of 3 noticeable parts: the checkboxes that determine session values, the form to generate strings and the box for displaying the generated result.

The checkboxes above are used to set and unset Flask server’s session values. They are controlled by the JQuery’s onChange event listener, which would use AJAX to call API:

(The function to call the API to send new values for the sessions. Returns a toast message)

The form and the progress bar

In addition to session values, the API to generate strings would require 2 arguments: the amount of string to generate and the string length. The values for them come from 2 number inputs:

Upon submitting the form, strings would be generated and the progress bar in the result box would be updated while the API is running.

The trackable API

Server-side

The trackable string generation API would emit a data message after every running instance. These messages are used for handling on the client side by updating the progress bar and display generated string. Here is an example of said message:

In that message, generated_string is the generated by looping through a set of characters (from the provided session values) and randomly picking one by one until it has the desirable length.

Once the loop is finished, the API should also emit a custom event for the browser to display a toast message.

In order to use session values, the for loop must become written as a function, then wrapped in a stream_with_context. Finally the API should return an HTTP response with a special mimetype text/event-stream.

Client-side

As mentioned, submitting the form would call the trackable API as an instance of the EventSource class. This kind of trackable API, however, is limited to the GET method and cannot accept any payload body, which is why URL arguments have to be used, like in this image:

Every yield from the API corresponds to a JSON-like data being sent to the browser and can be extracted for updating the progress bar and result box:

Once the API is done, the EventSource instance should be closed with a toast message, whether successful or not:

Future plan

There are other ways to develop a trackable API, such as WebSocket. This method is more superior due to:

Allowing other HTTP methods, aside from GET.
Allowing sending custom payload bodies.
Allowing intercommunication between client and server.

Perhaps, that can be a tutorial for another day.

I hope you enjoy this tutorial. Let me know if you have any questions by: Github or Email.

Thank you for your time.