Unique Relationship Entity

Question

Is there a simpler way to get a unique relationship entity than this?
@Entity
class CarPassedTruck {
    class Unique {
         @KeyField(1)
         String carLicense;
         @KeyField(2)
         String truckLicense;
         private Unique() {}
    @PrimaryKey
    long id;
    @SecondaryKey(relate=MANY_TO_ONE, relatedEntity=Car.class)
    String carLicense;
    @SecondaryKey(relate=MANY_TO_ONE, relatedEntity=Truck.class)
    String truckLicense;
    @SecondaryKey(relate=ONE_TO_ONE)
    Unique unique;
    private CarPassedTruck() {}
}If this is the best approach, would it be possible to get an annotation to handle the creation of this composite key automatically? The cleanest place to put one would seem to be as an array of @UniqueKey in the @PrimaryKey.
@PrimaryKey(unique={@UniqueKey("carLicense", "truckLicense")})

Answer 1

Hi,
I've been thinking about this and I think perhaps a more general solution would be a better addition to the DPL in the long run.
If I understand correctly from your example and code, your main intention is to avoid creating the Unique key class that contains the car and truck license fields. In your example a long ID is used as the unique primary key. However, another (possibly more common) approach would be to make the car/trunk license the one and only unique key as follows.
@Entity
class CarPassedTruck {
    static class CarTruckKey {
         @KeyField(1)
         String carLicense;
         @KeyField(2)
         String truckLicense;
         private CarTruckKey() {}
    @PrimaryKey
    CarTruckKey key;
    @SecondaryKey(relate=MANY_TO_ONE, relatedEntity=Car.class)
    String carLicense;
    @SecondaryKey(relate=MANY_TO_ONE, relatedEntity=Truck.class)
    String truckLicense;
    private CarPassedTruck() {}
}In this case, and possibly also in your example, the CarTruckKey class is needed in order to do lookups by this key in the index. Lacking tuples (like Python and Scala) in Java, such a key class is needed to specify a composite key, especially in general case where not all the fields are Strings.
This brings us to more a general issue in the DPL, which has been pointed out several times on the forum and that we do plan to address in the future, which is that it is cumbersome to share a field's value among more than one key. Today, sharing of values requires that the application copy the shared value into multiple field locations. This copying has to be done initially when the object is created, and whenever a shared field value is changed. You'll find a number of posts on the forum about this.
This issue comes up whenever composite keys are used, and a field in a composite key is also used in another key or as a non-key field. We have several ideas in mind for addressing this issue, for example:
<li>Allow a field in a key class to refer to another field or key by name, such that the copying is done automatically.
<li>Provide a way to define keys via methods, rather than fields, allowing the methods to derive the key value (whether singular or composite) from other fields in the object. This also allows deriving keys using computations on their source data, as opposed to just copying.
Another issue is that one would like to specify a foreign key constraint on a field in a composite key class, whether or not that field also appears as a separate key. One would like to specify a sequence, as well, on an individual field in a key class.
Initially I didn't recognize your feature request as related to these more general problems, and I apologize for that. And I'm sorry that I didn't give you this feedback before you wrote the code; that wasn't fair.
We are really in no position right now to do the design or implementation work required to address these enhancements in a thorough way; we'll need to put a lot of thought into this, in order to keep the DPL model as simple as possible. But these issues have been outstanding for a long time, so I can imagine that you and others may be a little frustrated that we're taking so long. We have to balance the time we put into the JE database storage engine itself with time we put into the DPL, so we definitely have constraints. But I can assure you that we are chipping away at some of the DPL enhancements that have been requested.
I'm not sure whether you'd like to do a local enhancement in your copy of JE that addresses your immediate needs, or if you'd rather wait for more general solutions to appear in JE later on. Whatever you choose to do, we'll support you the best we can with the time we have available.
Thanks,
--mark