Intershop EDL code generator does not generate setter methods for PO objects

Question

Is this normal and expected behaviour with Intershop code generator? If for example you have following interface Test.edl:

cartridge interface Test extends PersistentObject
{
    /*
     * Product ID
     */
    attribute productID : string required;

    /*
     * Test2 UUID
     */
    attribute test2UUID: uuid required;

    /**
     * Test2 relation
     */
    relation test2: Test2[1..1] readonly;

    /*
     * Product relation
     */
    relation product : Product[1..1] readonly;
}

cartridge interface Test2 extends PersistentObject
{
    relation test2values : Test[0..n] readonly;
}

and it's PO object:

orm class TestPO extends PersistentObjectPO implements Test table "Test"
{
     /**
     * Declare alternate key.
     */
    alternate key (test2UUID, productID, domainID);

    /**
     * Holds link to test2.
     */
    attribute test2UUID: uuid required;

    /**
     * Holds link to product.
     */
    attribute productID : uuid required;

    /**
     * Relation to test2 PO
     */
    relation test2PO : Test2PO[1..1] inverse testPOs implements test2 readonly 
    {
        foreign key(test2UUID) -> (UUID);
    }

    /**
     * Relation to product PO
     */
    dependency product : ProductPO
    {
        foreign key(productID);
    }

}

orm class Test2PO extends PersistentObjectPO implements Test2 table "Test2" {
    /**
     * Discount values relation
     */
    relation testPOs : TestPO[0..n] inverse test2PO implements test2values delete default;
}

Now if you generate code for both, interface and orm class. You'll get in interface Test.java with method setTest2UUID(String aValue), but implementation TestPO.java will be generated without it and because of that following compiler error:

"The type TestPO must implement the inherited abstract method Test.setTest2UUID(String)"

Are we doing something wrong here or is it a error in Intershop Code Generator?

Thank you for your answers!

Answer 1

Attribute test2UUID is modeled as being required. As far as I am concerned this will lead to a required parameter on the create-operation of the generated factory class. If you check SlotPageletAssignmentPO, it is modeled quite similar.

orm class SlotPageletAssignmentPO extends PersistentObjectPO implements SlotPageletAssignment table "SlotPageletAssignment"
{
    attribute id : string<256> required readonly;

    attribute parentSlotID : uuid required;

    attribute subPageletID : uuid required;

    attribute validFrom : datetime;

    attribute validTo : datetime;

    attribute online : boolean;

    attribute position : double required;

    relation subPageletPO : PageletPO[1..1] inverse parentSlotPageletAssignmentPOs implements subPagelet readonly
    {
        foreign key(subPageletID) -> (UUID);
    }

    relation parentSlotPO : SlotPO[1..1] inverse slotSubPageletAssignmentPOs implements parentSlot readonly
    {
        foreign key(parentSlotID) -> (UUID);
    }

    relation placeholderPO : SlotPageletAssignmentPlaceholderPO[0..n] inverse assignment readonly;
}

parentSlotID and subPageletID are both required UUIDs used by two relations that both implement relations declared in the capi interface.

cartridge interface SlotPageletAssignment extends PageletAssignment
{
    attribute id: string required readonly;

    attribute online : boolean;

    attribute validFrom : datetime;

    attribute validTo : datetime;

    attribute position : double required;

    /*
     * @deprecated Use {@link #getTo()} instead
     */
    relation parentSlot : Slot[0..1] readonly;

    /*
     * @deprecated Use {@link #getFrom()} instead
     */
    relation subPagelet : Pagelet[0..1] readonly;
}

As you can see merely the relation(s) but not the foreign key attributes that are part of the releation are declared on interface level. You could try that approach.