Update portion of a composite key?

Support
#1

Hi:

I solved the issue of linking to a portion of a composite key a few months ago (see [url=]https://www.cuba-platform.com/discuss/t/association-with-portion-of-an-embedded-key[/url]).

I just ran into an issue on version 6.5.3 (unless it was always here and I just didn’t notice!). I just tried to modify a portion of the composite key on a row. The changes are not saving. When I debug, I see that the datasource is not seeing the change (modified=false), so there is nothing to commit.

My entity declaration looks like this:

public class OfferCost extends BaseGenericIdEntity<OfferCostCompKey>  {
    private static final long serialVersionUID = 5003521880973026623L;

    @Column(name = "costppm", precision = 10, scale = 3)
    private BigDecimal costppm;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "CURRENCYCODE")
    private Currency currencycode;

    @JoinColumn(name = "OFFER_ID")
    @MapsId("offer_id")
    @ManyToOne(fetch = FetchType.LAZY)
    private Offer offer;

    @EmbeddedId
    private OfferCostCompKey id;

The OfferCostCompKey looks like this:

@Embeddable
public class OfferCostCompKey extends EmbeddableEntity {
    private static final long serialVersionUID = 8216541863980515194L;

    @Column(name = "OFFER_ID", nullable = false)
    private Long offer_id;

    @Temporal(TemporalType.DATE)
    @Column(name = "START_DATE", nullable = false)
    private Date startDate;

I am trying to update the startDate field. I know that modifying a primary key is not a particularly good practice, but I am working with legacy code and it does work in this particular case.

Does anybody know how to update a portion of a composite key?

#2

Hi,

Modification of composite PK fields is considered incorrect. Assumably the platform will create a new OfferCost as result of startDate modification.

One more thing in your code. Studio will generate DDL with two OFFER_ID columns, it could not be correctly executed.

#3

OK, thank you for the comments. How should it look instead to avoid two OFFER_ID columns? I thought the @MapsId took care of this?