Mod4j: Modeling for Java using Domain Specific Languages

No id set for newly added dto's (update-service method)

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Critical Critical
  • Resolution: Fixed
  • Affects Version/s: 1.1.0
  • Fix Version/s: 1.1.0
  • Component/s: DSL for Services
  • Labels:
    None
  • Number of attachments :
    0

Description

No id is set for newly added dto's to an existing object hierarchy when updated by the update-service method.

When updating an Xdto via the updateX service method, new objects get an id assigned at the end of the transaction (after flush). All translations from domain object to dto took place before that. There was no id set at that time.

Issue Links

This issue is related to:
MODFORJ-208 ConcurrentUpdateException Blocker Resolved
MODFORJ-138 The transaction advice is done on the LOCAL service instead of the DOMAIN service Minor Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Johan Vogelzang added a comment -

To see this effect in RecordShop
Unittest: testUpdateOrdersWithNewOrderLine in ThreeLevelsAssociationTests.java
Uncomment the line: //TODO MODFORJ-144 assertTrue(orderLineDto.getId() > 0);

Show
Johan Vogelzang added a comment - To see this effect in RecordShop Unittest: testUpdateOrdersWithNewOrderLine in ThreeLevelsAssociationTests.java Uncomment the line: //TODO MODFORJ-144 assertTrue(orderLineDto.getId() > 0);
Hide
Permalink
Johan Vogelzang added a comment -

We need to re-think the flushing strategy in this case. See code example below.
An intermediate flush must be performed right after the domainservice-update call. So the toDto() call right after that will be based on a Customer object with an assigned id (and version).

public CustomerWithOrdersAndOrderLines updateCustomer(CustomerWithOrdersAndOrderLines object) {
    
    Customer result = null;
    
    //...more code ...
    
    result = customerWithOrdersAndOrderLinesTranslator.fromDto(object, result);
    result = customerServiceModelDomainService.updateCustomer(result);

    // Explicit flush. So all newly added objects will get an id (and version) assigned.

    return customerWithOrdersAndOrderLinesTranslator.toDto(result);
}
Show
Johan Vogelzang added a comment - We need to re-think the flushing strategy in this case. See code example below. An intermediate flush must be performed right after the domainservice-update call. So the toDto() call right after that will be based on a Customer object with an assigned id (and version). 
public CustomerWithOrdersAndOrderLines updateCustomer(CustomerWithOrdersAndOrderLines object) {
    
    Customer result = null;
    
    //...more code ...
    
    result = customerWithOrdersAndOrderLinesTranslator.fromDto(object, result);
    result = customerServiceModelDomainService.updateCustomer(result);

    // Explicit flush. So all newly added objects will get an id (and version) assigned.

    return customerWithOrdersAndOrderLinesTranslator.toDto(result);
}
Hide
Permalink
Eric Jan Malotaux added a comment -

Temporary work-around: explicitly reread the object if you really need the id's filled in.

Show
Eric Jan Malotaux added a comment - Temporary work-around: explicitly reread the object if you really need the id's filled in.
Hide
Permalink
Johan Vogelzang added a comment -

Added explicit flush() to update methods in the dao's. So newly created objects will have a value for id before they are translated.

Show
Johan Vogelzang added a comment - Added explicit flush() to update methods in the dao's. So newly created objects will have a value for id before they are translated.

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.