Merge pull request #562 from gavinking/two-changes

three minor changes

Author: otaviojava

api/src/main/java/jakarta/data/repository/BasicRepository.java

@@ -25,6 +25,8 @@
 import java.util.Optional;
 import java.util.stream.Stream;
 
+import static jakarta.data.repository.By.ID;
+
 /**
  * <p>A built-in repository supertype for performing basic operations on entities.</p>
  *
@@ -141,7 +143,8 @@ public interface BasicRepository<T, K> extends DataRepository<T, K> {
      * @return the entity with the given Id or {@link Optional#empty()} if none is found.
      * @throws NullPointerException when the Id is {@code null}.
      */
-    Optional<T> findById(K id);
+    @Find
+    Optional<T> findById(@By(ID) K id);
 
     /**
      * Returns whether an entity with the given Id exists.
@@ -197,7 +200,8 @@ public interface BasicRepository<T, K> extends DataRepository<T, K> {
      * @param id must not be {@code null}.
      * @throws NullPointerException when the Id is {@code null}.
      */
-    void deleteById(K id);
+    @Delete
+    void deleteById(@By(ID) K id);
 
     /**
      * Deletes a given entity. Deletion is performed by matching the Id, and if the entity is

api/src/main/java/jakarta/data/repository/By.java

@@ -58,7 +58,7 @@
  * <p>The {@code By} annotation is unnecessary when the method parameter name
  * matches the entity attribute name and the application is compiled with the
  * {@code -parameters} compiler option that makes parameter names available
- * at run time.</p>
+ * at runtime.</p>
  *
  * <p>Thus, when this compiler option is enabled, the previous example may be
  * written without the use of {@code By}:</p>

api/src/main/java/jakarta/data/repository/Param.java

@@ -43,7 +43,7 @@
  * <p>The {@code Param} annotation is unnecessary when the method parameter name
  * matches the query language named parameter name and the application is compiled with the
  * {@code -parameters} compiler option that makes parameter names available
- * at run time.</p>
+ * at runtime.</p>
  *
  * @see Query
  */

api/src/main/java/jakarta/data/repository/Query.java

@@ -42,7 +42,7 @@
  * The {@code Param} annotation is unnecessary for named parameters when the method parameter name
  * matches the query language named parameter name and the application is compiled with the
  * {@code -parameters} compiler option that makes parameter names available
- * at run time. When the {@code Param} annotation is not used, the Jakarta Data provider must
+ * at runtime. When the {@code Param} annotation is not used, the Jakarta Data provider must
  * interpret the query by scanning for the delimiter that is used for positional parameters.
  * If the delimiter appears for another purpose in a query that requires named parameters,
  * it might be necessary for the application to explicitly define the {@code Param} in order to

api/src/main/java/jakarta/data/repository/package-info.java

@@ -30,7 +30,7 @@
  *     and {@link jakarta.data.repository.CrudRepository#update(java.lang.Object)} operations.</li>
  * </ul>
  *
- * <p>Repository interfaces can also define their own life cycle methods using the
+ * <p>Repository interfaces can also define their own lifecycle methods using the
  * {@link jakarta.data.repository.Insert}, {@link jakarta.data.repository.Update}, {@link jakarta.data.repository.Save}, and {@link jakarta.data.repository.Delete} annotations,
  * as well as a variety of other methods following the Query by Method Name pattern,
  * the Parameter-based Conditions pattern, and the {@link jakarta.data.repository.Query} annotation.</p>

api/src/main/java/module-info.java

@@ -236,7 +236,7 @@
  * <p>Repository methods following the <b>Query by Method Name</b> pattern
  * must include the {@code By} keyword in the method name and must not include
  * the {@code @Find} annotation, {@code @Query} annotation, or
- * any life cycle annotations on the method or any data access related annotations
+ * any lifecycle annotations on the method or any data access related annotations
  * on the method parameters. Query conditions
  * are determined by the portion of the method name following the {@code By} keyword.</p>
  *
@@ -572,7 +572,7 @@
  * If the {@link By} annotation is missing, the method parameter name must
  * match the name of an entity attribute and the repository must be compiled
  * with the {@code -parameters} compiler option so that parameter names are
- * available at run time. The {@code _} character may be used in a method
+ * available at runtime. The {@code _} character may be used in a method
  * parameter name to reference embedded attributes. All conditions are
  * considered to be the equality condition. All conditions must match in
  * order to retrieve an entity.</p>

spec/src/main/asciidoc/repository.asciidoc

@@ -826,7 +826,7 @@ A _parameter-based automatic query method_ is an abstract method annotated with
 
 Each automatic query method must be assigned an entity type. The rules for inferring the entity type depend on the semantics of the automatic query annotation. Typically:
 
-- If the automatic query method returns an entity type, the method return type identifies the entity. For example, the return type might be `E`, `Optional<E>`, `Page<E>`, or `List<E>`, where `E` is an entity class. Then the automatic query method would be assigned the entity type `E`.
+- If the automatic query method returns an entity type, the method return type identifies the entity. For example, the return type might be `E`, `Optional<E>`, `E[]`, `Page<E>`, or `List<E>`, where `E` is an entity class. Then the automatic query method would be assigned the entity type `E`.
 - If the query does not return an entity type, the entity assigned to the automatic query method is the primary entity type of the repository.
 
 Jakarta Data infers a query based on the parameters of the method. Each parameter must either:
@@ -1677,5 +1677,5 @@ The following order, with the lower number having higher precedence, is used whe
 4. If the method is annotated with an <<Parameter-based automatic query methods,automatic query annotation>>, such as `@Find`, or with a <<Lifecycle methods,lifecycle annotation>> declaring the type of operation, for example, with `@Insert`, `@Update`, `@Save`, or `@Delete`, and the provider recognizes the annotation, then the annotation determines how the method is implemented, possibly with the help of other annotations present on the method parameters, for example, any `@By` annotations of the parameters.
 5. If the method is named according to the conventions of _Query by Method Name_, then the implementation follows the <<Query by Method Name,_Query by Method Name_>> pattern.
 
-A repository method that does not fit any of the above patterns and is not handled as a vendor-specific extension to the specification must either result in an error at build time or raise `UnsupportedOperationException` at run time.
+A repository method that does not fit any of the above patterns and is not handled as a vendor-specific extension to the specification must either result in an error at build time or raise `UnsupportedOperationException` at runtime.
 

tck/src/main/java/ee/jakarta/tck/data/framework/read/only/CustomRepository.java

@@ -25,7 +25,7 @@
 /**
  * Do not add methods or inheritance to this interface.
  * Its purpose is to test that without inheriting from a built-in repository,
- * the life cycle methods with the same entity class are what identifies the
+ * the lifecycle methods with the same entity class are what identifies the
  * primary entity class to use for the count and exist methods.
  */
 @Repository

tck/src/main/java/ee/jakarta/tck/data/standalone/entity/EntityTests.java

@@ -1348,7 +1348,7 @@ public void testPageOfNothing() {
         assertEquals(0L, page.totalPages());
     }
 
-    @Assertion(id = "133", strategy = "Use count and exists methods where the primary entity class is inferred from the life cycle methods.")
+    @Assertion(id = "133", strategy = "Use count and exists methods where the primary entity class is inferred from the lifecycle methods.")
     public void testPrimaryEntityClassDeterminedByLifeCycleMethods() {
         assertEquals(4, customRepo.countByIdIn(Set.of(2L, 15L, 37L, -5L, 60L)));