Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for @JoinColumn #1952

Open
rfelgent opened this issue Nov 28, 2024 · 9 comments
Open

Add support for @JoinColumn #1952

rfelgent opened this issue Nov 28, 2024 · 9 comments
Labels
type: enhancement A general enhancement

Comments

@rfelgent
Copy link

rfelgent commented Nov 28, 2024

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

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Nov 28, 2024
@rfelgent
Copy link
Author

rfelgent commented Dec 1, 2024

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

@schauder schauder added type: enhancement A general enhancement and removed status: waiting-for-triage An issue we've not yet triaged labels Dec 2, 2024
@schauder
Copy link
Contributor

schauder commented Dec 2, 2024

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
Copy link
Author

rfelgent commented Dec 2, 2024

Of course I can wait @schauder.

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

@schauder
Copy link
Contributor

schauder commented Dec 2, 2024

Yes, I do think this is absolutely reasonable.

@kap199297
Copy link

kap199297 commented Dec 11, 2024

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
Copy link
Contributor

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
Copy link

@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
Copy link
Contributor

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
Copy link

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. 😊

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

4 participants