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

Support for JPA like features - @ManyToOne, @OneToMany annotations #352

Closed
dkalaria opened this issue Apr 20, 2020 · 4 comments
Closed

Support for JPA like features - @ManyToOne, @OneToMany annotations #352

dkalaria opened this issue Apr 20, 2020 · 4 comments
Labels
status: invalid An issue that we don't feel is valid

Comments

@dkalaria
Copy link

No description provided.

@mp911de
Copy link
Member

mp911de commented Apr 21, 2020

Can you elaborate on the actual features you would like to see and tell us a bit about your use-case that you're trying to solve? Referencing JPA and a few annotations can span a pretty huge feature space.

@dkalaria
Copy link
Author

The spring-data-common and spring-data-relational annotations are available for use but are limited.
If we can enhance current annotation available in JPA and add new ones that would be helpful:

Updating annotations:

  • @Column to include length of the field and isNullable
  • @Table to include schema value along with table name
  • @GeneratedValue - to select the strategy for generating the unique value like Identity, Sequence or Auto

New Annotations:

  • @Basic - to use lazy and eager fetching of the field
  • @MappedSuperclass - to support inheritance for child class
  • @AttributeOverride - to rename the super class attribute for a child class

@mp911de
Copy link
Member

mp911de commented Apr 22, 2020

Thanks for the details. We do not plan on adding schema generation and lazy fetching isn't an option either as reactive programming does not allow for blocking operations. Introducing additional wrapper types would pollute the domain model for non-blocking, lazy loading. So eager fetching is really the only option.

Also, for eager fetching we cannot come up with something beyond the first level of reference as that is basically the limit of joins in queries. Right now, you can model arbitrary subclass hierarchies where you end up with a table per class. However, polymorphic queries are not supported and I expect us not following that path as polymorphic querying introduces a lot of complexity providing only little value. So what really is then left over is the ID generation strategy.

@mp911de mp911de added status: declined A suggestion or change that we don't feel we should currently apply status: invalid An issue that we don't feel is valid and removed status: declined A suggestion or change that we don't feel we should currently apply labels Apr 24, 2020
@mp911de
Copy link
Member

mp911de commented Apr 24, 2020

Can you create a new ticket for ID generation? Closing this ticket as it's too broadly formulated and hard to understand what's left over.

@mp911de mp911de closed this as completed Apr 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: invalid An issue that we don't feel is valid
Projects
None yet
Development

No branches or pull requests

2 participants