Creating, Updating, Deleting Objects

Creating Objects

Create Customer (Without Address)

To create a customer, use the save method .

@PostMapping("api/v1/createCustomer/")
public WebResponse createCustomer(@TQLContext CustomUserContext userContext, 
    @RequestBody CustomerCreationRequest request) {

    Customer newCustomer = createCustomerFromRequest(request).updateName();
    newCustomer.save(userContext);
    return WebResponse.success();
}

private Customer createCustomerFromRequest() {
    // Implementation here
    return new Customer();
}

• All fields and sub list will be checked in save method
• use context.checkAndFix(Object) to check only

Create Customer (With Address)

To create a customer with addresses, use save to validate required fields.

@PostMapping("api/v1/createCustomer/")
public WebResponse createCustomer(@TQLContext CustomUserContext userContext, 
    @RequestBody CustomerCreationRequest request) {

    Customer newCustomer = createCustomerFromRequest(request)
        .appendAddress(createAddressesFromRequest(request))
        .updateName();
    return WebResponse.success();
}

private Customer createCustomerFromRequest() {
    // Implementation here
    return new Customer();
}

private SmartList<Address> createAddressesFromRequest() {
    // Implementation here
    return new SmartList<>();
}

After creation, the version of the object will be set to 1.

---

Updating Objects

Update Customer

Use the save method to update an existing customer. The version will be incremented by 1 after the update.

@PutMapping("api/v1/updateCustomer/")
public WebResponse updateCustomer(@TQLContext CustomUserContext userContext, 
    @RequestBody CustomerUpdateRequest request) {

    Customer updatedCustomer = loadCustomerForUpdate(userContext, request);
    updatedCustomer.save(userContext);
    return WebResponse.success();
}

private Customer loadCustomerForUpdate(@TQLContext CustomUserContext userContext,
    CustomerUpdateRequest request) {
    Customer customer = // Load customer by ID or other criteria
    customer.updateName(request.getName());
    return customer;
}

---

Deleting Objects

Delete Customer

To delete a customer, mark it for removal and use the save method. The version will become a negative number after the deletion.

@DeleteMapping("api/v1/deleteCustomer/")
public WebResponse deleteCustomer(@TQLContext CustomUserContext userContext, 
    @RequestBody CustomerDeleteRequest request) {

    Customer customer = loadCustomerForDelete(userContext, request);
    customer.markToRemove();
    customer.save(userContext);

    return WebResponse.success();
}

private Customer loadCustomerForDelete(@TQLContext CustomUserContext userContext,
    CustomerDeleteRequest request) {
    Customer customer = // Load customer by ID or other criteria
    return customer;
}

After deletion, the version of the object will be set to a negative number.

---

Mutation Engine and Transaction Boundaries

TeaQL treats save as a mutation operation over an object graph.

When an entity is saved, the runtime:

• checks and fixes the entity graph before persistence
• collects changed entities from the graph
• groups them by repository type
• assigns IDs for new entities
• dispatches each entity as create, update, delete, or recover based on its internal status
• lets the concrete repository perform the database-specific write

The mutation engine does not own the transaction boundary. This is intentional.

A business operation may need to combine multiple save calls into one atomic unit. For that reason, transactions should be declared at the service or application-use-case layer, for example with Spring's @Transactional.

@Transactional
public void changeCustomerAndOrders(CustomUserContext userContext, ChangeRequest request) {
    Customer customer = loadCustomer(userContext, request);
    customer.updateName(request.getName());
    customer.save(userContext);

    Order order = loadOrder(userContext, request);
    order.updateStatus(request.getOrderStatus());
    order.save(userContext);
}

In this shape, TeaQL handles graph mutation and repository dispatch, while the surrounding service method decides whether several writes should commit or roll back together.