Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/NicolasMPP/restorante-springboot/llms.txt

Use this file to discover all available pages before exploring further.

Restorante’s persistence layer is built on a set of JPA entities that map the full lifecycle of restaurant operations — from staff management through to menu composition. Two distinct inheritance strategies are used: JOINED for the Persona hierarchy (each subclass occupies its own table, joined on the primary key) and SINGLE_TABLE for both the Alimento and Empleado hierarchies (all subtypes share one table, distinguished by a discriminator column). This combination keeps staff identity data normalized while keeping food and employee-role queries fast.

Core Entities

Persona

Table: personasBase class for all people in the system. Uses JOINED inheritance — every subclass stores its own additional columns in a separate table, linked back to personas by primary key.
FieldTypeConstraints
idIntegerAuto-generated PK
nombreStringNot null, max 100 chars
cedulaStringNot null, unique, 7–20 chars
telefonoStringOptional, max 20 chars
correoStringOptional, max 100 chars
usuarioStringOptional, max 50 chars
contraseniaStringOptional, max 100 chars

Empleado

Table: empleadosExtends Persona via JOINED inheritance (@PrimaryKeyJoinColumn(name = "id")). Uses its own SINGLE_TABLE inheritance for employee subtypes (Chef, Mesero), controlled by the tipo_empleado discriminator column.
FieldTypeConstraints
fechaVinculacionLocalDateHire date
horaIngresoLocalDateTimeStart of shift
horaSalidaLocalDateTimeEnd of shift
salarioBigDecimalPrecision 10, scale 2
Has a @OneToMany relationship with Receta (mapped by chef field on the recipe side).

Chef

Discriminator: CHEF in tipo_empleadoExtends Empleado. Adds no new columns — its type is distinguished purely by the discriminator value. Chefs are the primary assignees for Receta entities and are looked up by cédula when creating or updating food items.

Mesero

Discriminator: MESERO in tipo_empleadoExtends Empleado. Shares the empleados table with Chef and the base Empleado discriminator value. No additional columns or special API operations beyond standard employee management.

Gerente

Table: gerentesExtends Persona via JOINED inheritance. Stores no extra columns but owns Menu and Despensa entities via @OneToMany relationships (cascaded ALL). Every Menu and Despensa record must reference a Gerente.

Cliente

Table: clientesExtends Persona via JOINED inheritance. Represents a customer — not an employee and carries no salary or scheduling fields. Stores no additional columns beyond those inherited from Persona.

Alimento

Table: alimentosBase food entity. Uses SINGLE_TABLE inheritance with discriminator column tipo_alimento. All food subtypes (PlatoFuerte, Postres, Bebida, Adicionales) are stored in this single table.
FieldTypeConstraints
idIntegerAuto-generated PK
nombreStringNot null, max 100 chars
precioBigDecimalNot null, precision 10 scale 2
recetaRecetaManyToOne, nullable (receta_id FK)
menusList<Menu>ManyToMany inverse side

Menu

Table: menuOwned by one Gerente (@ManyToOne, not nullable). Contains many Alimento entries via the menu_alimentos join table. Also carries an optional nombreMenu field (max 100 chars).

Despensa

Table: despensaOwned by one Gerente (@ManyToOne, not nullable). Holds many Ingrediente records via the despensa_ingredientes join table. Provides stock visibility and low-stock querying at the business-logic layer.

Receta

Table: recetasBelongs to one Empleado (the chef who authored it) via @ManyToOne. Uses many Ingrediente records via the receta_ingredientes join table.
FieldTypeConstraints
idIntegerAuto-generated PK
nombreRecetaStringNot null, max 100 chars
descripcionProcesoStringTEXT column

Ingrediente

Table: ingredientesRepresents a single ingredient with a stock counter. Participates in two independent many-to-many relationships: with Receta (which recipes use this ingredient) and with Despensa (which pantries stock it).
FieldTypeConstraints
descripcionStringNot null, max 100 chars
cantidadStockIntegerNot null, ≥ 0

Entity Relationship Overview

The following describes how entities connect across the full restaurant workflow:
  • A Gerente owns one or more Menu instances and one or more Despensa instances (both via @OneToMany with cascade ALL).
  • Each Menu holds many Alimento items, linked through the menu_alimentos join table.
  • Each Alimento optionally references one Receta (the receta_id FK is nullable, so drinks and desserts without preparation steps can have a null recipe).
  • Each Receta belongs to one Empleado (typically a Chef) and uses many Ingrediente records, linked through receta_ingredientes.
  • Each Despensa stores many Ingrediente records, linked through despensa_ingredientes. Ingredients are therefore shared data — the same Ingrediente row may appear in both a recipe and the pantry.

Join Tables

Join TableOwning EntityFK ColumnInverse FK Column
menu_alimentosMenumenu_idalimento_id
despensa_ingredientesDespensadespensa_idingrediente_id
receta_ingredientesRecetareceta_idingrediente_id
All three join tables are managed by the owning side of the @ManyToMany relationship. The inverse sides on Alimento, Despensa, and Ingrediente use mappedBy and carry @JsonIgnore to prevent serialization cycles.

Inheritance Strategies

All food types share the alimentos table. The tipo_alimento string column acts as the discriminator.
-- Discriminator column definition
-- @DiscriminatorColumn(name = "tipo_alimento", discriminatorType = DiscriminatorType.STRING)

SELECT tipo_alimento, COUNT(*) FROM alimentos GROUP BY tipo_alimento;
Discriminator ValueJava Class
GENERALAlimento (base)
PLATO_FUERTEPlatoFuerte
POSTREPostres
BEBIDABebida
ADICIONALAdicionales
None of the subtypes add extra columns — the tipo_alimento value is the sole differentiator. This makes polymorphic queries across all food types a single-table scan.

Build docs developers (and LLMs) love