Add support for @JoinColumn

[rfelgent]

Hi,

I love the simplicity of spring-data-jdbc, but sometimes it feels too restrictive compared to possibilities of JPA. I miss the @JoinColumn feature.

Please let me describe my need for it

class Order {
   @Id
   String id;                        // technically, randomly generated value without _any_ business meaning, e.g. UUID
   String reference ;           // some kind of business information encoded in the value and it is _unique_ (!)
   @MappedCollection
   Set<OrderItem> orderItems;
   // might be a better name compared to @JoinColumn
   //@MappedColumn
   @JoinColumn("reference")  // <== not using the "id" field
   private Meta meta;
}

class OrderItem {
   @Id
   Long id;                      // technical id
   String orderId;            // back reference to Order
}

class Meta {
   @Id
   String reference;
   String data;
}

I have use cases, where relations are either based on that unique field/property/column or on another unique field/property/column.
I tried to use the NamingStrategy to achieve my goal, but it didn't work either.

best regards

[rfelgent]

Hmmm... @schauder , is there anything I can do in order to push my Feature request?

[schauder]

Most of the time I'd say provide a PR, but currently I'm working on a feature that changes a lot of stuff in the areas that would be touched by a PR. Such a PR would therefore run into a lot of conflicts. But if you wait until said feature is done, a PR would be welcome, but probably quite challenging.

[rfelgent]

Of course I can wait @schauder.

The first question for me: is the feature request itself reasonable ? what do you think?

[schauder]

Yes, I do think this is absolutely reasonable.

[kap199297]

I am new to Spring Data JDBC. If there is support for @JoinColumn based on a non-primary column, we can technically use it for Many to Many and Many to One. Right? Please correct me If I have misunderstood the requirement.

[schauder]

I am new to Spring Data JDBC. If there is support for @joincolumn based on a non-primary column, we can technically use it for Many to Many and Many to One. Right? Please correct me If I have misunderstood the requirement.

There is no support for @JoinColumn but, even when there eventually is, there will be no support for Many-to-Many nor Many-to-One. See https://spring.io/blog/2018/09/24/spring-data-jdbc-references-and-aggregates for details.

[kap199297]

@schauder Thanks for providing the references. I got the idea of aggregates with root entities. But I have one query if you are happy to answer it.
Just consider any scenario of employee and asset where there is no foreign key relationship between tables and both have a common column saying employerCode.

class EmployerUser {
   @Id
   String id;                        
   String employeeCode;    // UniqueEmployeeCode, This can be null for contractors/any other type of users
   @JoinColumn("employeeCode") // Join Column reference to Asset Table
   Set<Asset> assets;
}

class Asset {
   @Id
   String id;
   String assetCode;
   String employeeCode; // No foreign key relationship
   String name;
   @JoinColumn("employeeCode") // Join Column reference to Asset Table
   @ReadOnlyProperty
   EmployerUser assets;
}

I know, it is not possible to persist data based on these mappings. But technically, we can get the data from entity mapping the common column if @joincolumn is implemented in the future. Please correct my understanding if I have misunderstood anything.
Thanks in advance. 😊

[schauder]

No. A mapping like this will still either cause a stackoverflow or some custom error due to a recursive definition of an aggregate. JoinColumn will not change the structure of mappings that are possible. Instead it will only change, which id to be used for a back reference.

[kap199297]

Thanks @schauder, I got your point related to the bi-directional mapping.

I got your answer from stack overflow that as per Spring boot JDBC implementation, it will fetch all information at the same time and doesn't have Lazy Loading principle. 😊

[rfelgent]

Most of the time I'd say provide a PR, but currently I'm working on a feature that changes a lot of stuff in the areas that would be touched by a PR. Such a PR would therefore run into a lot of conflicts. But if you wait until said feature is done, a PR would be welcome, but probably quite challenging.

Hi @schauder , what is the current status. I would like dive into making a merge request.

[schauder]

Once this PR is done #1957 I'm happy to look at PRs for JoinColumn. Of course, you could start working on a solution based on that PR hoping that it doesn't change to much before getting merged.