Derived Model denormalized fields update (adapter)

Posts   
 
    
Posts: 19
Joined: 29-Jun-2017
# Posted on: 15-Jul-2017 03:45:43   

LLBLGenPro v5.2 Using Derived Model DTO: Say I de-normalize a field (eg Order table has an EmployeeID fk to Employee table with EmployeeName and I create an Order DTO with the EmployeeName); now I use the DTO in my code... say the client updated the EmployeeID and I save it ... the EmployeeName is not changed - I need to reload the DTO from the database to get the good EmployeeName. In other words:

//order contains a new, modified EmployeeID (but the old EmployeeName)
using (var adapter = new DataAccessAdapter())
{
    var metaData = new LinqMetaData(adapter);
    var entity = metaData.Order.FirstOrDefault(OrderPersistence.CreatePkPredicate(order));
    if (entity == null) return Request.CreateResponse(HttpStatusCode.NotFound);
    entity.UpdateFromOrder(order);
    adapter.SaveEntity(entity);
    // If I do not add the following line, order contains the new EmployeeID but the old (wrong) EmployeeName.
    // If I have the line, then order contain the new (right) EmployeeName (the one attached to the new EmployeeID)
    order = (from o in metaData.Order where o.UID == order.UID select o).ProjectToOrder().ToList()[0];
}

Q1) Is this by design or is this a setup somewhere? Is there a way to automatically have the entity always reloaded? For example there may be columns calculated in the database by a trigger when a line is updated and we need the new values in the DTO every time we do an update to the database. Q2) Perhaps I am not using this feature the right way? If that is the case, could you educate me please? Q3) The way I described the Derived Model (denormalizing the EmployeeName): is this the typical use-case for Derived Models ? Is this why Derived Models were designed ?

Thank you!

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 15-Jul-2017 09:50:39   

FrankMonroe wrote:

LLBLGenPro v5.2 Using Derived Model DTO: Say I de-normalize a field (eg Order table has an EmployeeID fk to Employee table with EmployeeName and I create an Order DTO with the EmployeeName); now I use the DTO in my code... say the client updated the EmployeeID and I save it ... the EmployeeName is not changed - I need to reload the DTO from the database to get the good EmployeeName. In other words:

//order contains a new, modified EmployeeID (but the old EmployeeName)
using (var adapter = new DataAccessAdapter())
{
    var metaData = new LinqMetaData(adapter);
    var entity = metaData.Order.FirstOrDefault(OrderPersistence.CreatePkPredicate(order));
    if (entity == null) return Request.CreateResponse(HttpStatusCode.NotFound);
    entity.UpdateFromOrder(order);
    adapter.SaveEntity(entity);
    // If I do not add the following line, order contains the new EmployeeID but the old (wrong) EmployeeName.
    // If I have the line, then order contain the new (right) EmployeeName (the one attached to the new EmployeeID)
    order = (from o in metaData.Order where o.UID == order.UID select o).ProjectToOrder().ToList()[0];
}

Q1) Is this by design or is this a setup somewhere? Is there a way to automatically have the entity always reloaded? For example there may be columns calculated in the database by a trigger when a line is updated and we need the new values in the DTO every time we do an update to the database.

Denormalized fields aren't updated in a DTO, that's by design. Your code assumes that if you update the entity it will magically update the DTO as well, but that's not the case: DTOs are projection results from a query, you can alter the data inside them, and use that data to change entities fetched from the DB, but the DTO isn't updated in that process: you have to re-project a query again to DTOs.

Q2) Perhaps I am not using this feature the right way? If that is the case, could you educate me please?

You're using the feature as intended simple_smile The DTO's life ends when it's used to update an entity. You should then toss it away and fetch a new version for another cycle.

Q3) The way I described the Derived Model (denormalizing the EmployeeName): is this the typical use-case for Derived Models ? Is this why Derived Models were designed ? Thank you!

Among other reasons, yes. It's a way to create a different model, projected from an entity model, for a different use-case than entities, where you don't need the entity code (e.g. you return them from a service so they're converted to JSon). In most cases, DTOs are used in read-only scenarios, e.g. for data for views in MVC.

Frans Bouma | Lead developer LLBLGen Pro