Por qué las personalizaciones de Odoo son más rápidas mediante la API que con SQL
Los permisos, las propiedades y las traducciones se pueden modificar en pocas líneas mediante la consola de Odoo. Un enunciado SQL suele requerir varias consultas previas para ello.
Otorgar permisos sin tocar la base de datos
En el soporte se necesita a alguien con derechos de administrador, y eso de inmediato. El camino más corto parece ser a través de la base de datos: un UPDATE en la tabla de permisos, listo. A través de la shell de Odoo son dos líneas, y todas las comprobaciones se ejecutan.
user = env['res.users'].search([('login', '=', 'benutzer@example.com')])
user.write({'group_ids': [Command.link(env.ref('base.group_system').id)]})
env.cr.commit()
La shell está incluida en cada instalación. Una llamada con odoo-bin shell -d <datenbank>la inicia, sin que un servidor web se inicie ni que la operación en producción lo note.
Lo que write y commit realmente hacen
write() es el camino de escritura regular del modelo de datos. Verifica los datos obligatorios y los rangos de valores, recalcula los campos de cálculo almacenados, tiene en cuenta las reglas de acceso y registra quién cambió el registro. Un UPDATE omite todo eso y solo inserta el valor.
env.cr.commit() confirma la transacción. La shell descarta cualquier cambio al salir, lo que regularmente cuesta a los principiantes su trabajo.
La regla detrás de esto es simple. Lo que se puede lograr más fácilmente a través de la API no se hace manualmente con SQL.
En Properties, SQL primero recopila datos
La distancia entre ambos caminos aumenta cuando los datos están anidados. Odoo almacena Properties como JSON, y el valor por sí solo está en el registro. La definición asociada con tipo y valor predeterminado se encuentra en el registro superior, por ejemplo, el proyecto de la tarea.
Quien quiera cambiarlo mediante SQL, primero determina el registro principal, lee la definición de un campo JSON, busca la clave interna de la propiedad deseada y construye la operación JSON para el registro real. Cuatro pasos antes de que la sentencia esté completa. Un write() en el campo realiza la misma tarea en una línea, porque Odoo combina la definición y el valor por sí mismo.
Las traducciones están en JSON desde Odoo 16
Los campos traducibles también los guarda Odoo como JSON, con una entrada por idioma en la misma columna. La tabla de traducción anterior ya no existe.
Con SQL, la edición de JSON ocurre exactamente en el lugar correcto, sin dañar los demás idiomas. Con la API basta un cambio de idioma en el contexto:
produkt = env['product.template'].browse(42)
produkt.with_context(lang='de_DE').write({'name': 'Bürostuhl'})
env.cr.commit()
El texto en inglés permanece intacto, porque Odoo direcciona la entrada correspondiente por sí mismo.
Cuándo SQL sigue siendo la herramienta adecuada
Quedan dos casos. Si el modelo de datos no se carga debido a módulos bloqueados, tampoco se inicia la shell, y una intervención SQL es la única forma de volver. En cambios masivos con más de seis cifras de filas, el desvío a través del ORM consume más tiempo que las verificaciones valen. Luego, la recalculación de los campos de cálculo afectados debe realizarse después.
Para todo lo demás, la shell es el camino más corto. La llamada dura segundos, y la primera consulta ya revela si la expresión de búsqueda coincide con lo que debe coincidir. La Documentación de Odoo para la línea de comandos describe los parámetros restantes.