-
Notifications
You must be signed in to change notification settings - Fork 32
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
JPA specialization [Proposal] #140
Changes from all commits
876a198
f28001b
1b0e6f3
518f0a4
432a310
46af832
25d34c4
9e75483
b7eec04
986e870
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -106,7 +106,7 @@ | |
* <code>findByAddress_ZipCode</code> or <code>findByAddressZipCode</code>) | ||
* when referred to within repository method names, and delimited by | ||
* <code>.</code> when used within annotation values, such as for | ||
* {@link OrderBy#value} and {@link Query#value},</p> | ||
* {@link jakarta.data.repository.jpa.OrderBy#value} and {@link Query#value},</p> | ||
* | ||
* <pre> | ||
* @Entity | ||
|
@@ -528,6 +528,7 @@ | |
// TODO Does Jakarta NoSQL have the same or different wildcard characters? Document this | ||
// under: "Wildcard characters for patterns are determined by the data access provider" | ||
// TODO Ensure we have all required supported return types listed. | ||
//TODO move away all transaction details to keep it more generic as possible | ||
@Documented | ||
@Retention(RetentionPolicy.RUNTIME) | ||
@Target(ElementType.TYPE) | ||
|
@@ -537,38 +538,8 @@ | |
* available Jakarta Data provider that supports the type of entity | ||
* annotation that is present on the repository's entity class. | ||
*/ | ||
static final String ANY_PROVIDER = ""; | ||
String ANY_PROVIDER = ""; | ||
|
||
/** | ||
* Value for the {@link dataStore} attribute that indicates that the | ||
* Jakarta Data provider should choose a default data store to use. | ||
* The default data store might require additional vendor-specific | ||
* configuration, depending on the vendor. | ||
*/ | ||
static final String DEFAULT_DATA_STORE = ""; | ||
|
||
/** | ||
* <p>Optionally indicates the data store to use for the repository.</p> | ||
* | ||
* <p>The Jakarta Data specification does not define a full configuration | ||
* model, and relies upon the Jakarta Data providers to provide configuration. | ||
* This value serves as an identifier linking to vendor-specific configuration | ||
* for each Jakarta Data provider to interpret in a vendor-specific way.</p> | ||
* | ||
* <p>For some Jakarta Data providers, this value could map directly to an | ||
* identifier in vendor-specific configuration. For others, this value could | ||
* map to a base configuration path that forms a configuration hierarchy, | ||
* such as in MicroProfile Config, or possibly Jakarta Config in a future | ||
* version of this specification. For providers backed by Jakarta Persistence, | ||
* it might point to a {@code jakarta.annotation.sql.DataSourceDefinition} name | ||
* or a {@code javax.sql.DataSource} JNDI name or resource reference, | ||
* or other vendor-specific configuration.</p> | ||
* | ||
* <p>The default value of this attribute is {@link #DEFAULT_DATA_STORE}.</p> | ||
* | ||
* @return the name of a data store or {@link #DEFAULT_DATA_STORE}. | ||
*/ | ||
String dataStore() default DEFAULT_DATA_STORE; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is not specific to Jakarta Persistence. It applies to every type of backend where there can be multiple, which is all types I'm aware of. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Usually, we're using convention over configuration allied with The Twelve-Factor App: That is why I proposed to keep it on JPA subdomain. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't follow this argument at all with respect to what it has to do with JPA being the deciding factor in whether or not you are able to use multiple databases. |
||
|
||
/** | ||
* <p>Restricts the repository implementation to that of a specific | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not specific to Jakarta Persistence. Page counts and total element counts across all pages apply to every type of database that supports pagination.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is not valid.
You can paginate using a stream or any "pointer" or cursor of this data.
Samples:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, I didn't word that very well. The point is that although not all databases can count total results, types other than Jakarta Persistence/JPA do have that ability and it is therefore wrong to restrict it to Jakarta Persistence/JPA alone. We know for a fact that JDBC can do this via SQL independently of Jakarta Persistence. Even MongoDB which you cited as a counter example exposes an API for counting documents so it is not unreasonable to allow for the possibility they might some day want to let the same thing to be done via whatever query language they support. If a count query isn't useful for a particular type that doesn't support it, then just don't use it with those types. But let it remain for all of those where it useful. It seems like you are boxing in and limiting everything that isn't Jakarta Persistence where it isn't necessary and doesn't make sense.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, some databases can support count, but why not use OOP in our favor and create specializations?
It is the beauty of OOP!
You can have generic and specializations instead of having several optional methods.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Specializations should be used where they make sense - when there are categories that provide accurate delineation between where a function is applicable versus not applicable. We have been struggling to find that clear separation here. JPA vs everything else and relational vs everything else don't perfectly fit. While we can state that Jakarta Persistence will always have certain capabilities, we cannot accurately state that non-JPA will always not.