Merge pull request #275 from njr-11/missed-renames

Renames that were missed in JavaDoc, spec, and TCK

README.adoc

@@ -14,7 +14,7 @@ A repository abstraction designed to significantly reduce the boilerplate code r
 [source,java]
 ----
 @Repository
-public interface CarRepository extends CrudRepository<Car, Long> {
+public interface CarRepository extends BasicRepository<Car, Long> {
 
   List<Car> findByType(CarType type);
 

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

@@ -51,7 +51,7 @@
  *
  * <pre>
  * &#64;Repository
- * public interface Products extends CrudRepository&lt;Product, Long&gt; {
+ * public interface Products extends BasicRepository&lt;Product, Long&gt; {
  *
  *     &#64;OrderBy("price")
  *     List&lt;Product&gt; findByNameIgnoreCaseLikeAndPriceLessThan(String namePattern, float max);
@@ -706,7 +706,7 @@
  *
  * <pre>
  * &#64;Repository
- * public interface Cars extends CrudRepository&lt;Car, Long&gt; {
+ * public interface Cars extends BasicRepository&lt;Car, Long&gt; {
  *     ...
  *
  *     EntityManager getEntityManager();

spec/src/main/asciidoc/jakarta-ee.adoc

@@ -11,7 +11,7 @@ One of the critical aspects of CDI integration with Jakarta EE Data is the abili
 [source,java]
 ----
 @Repository
-public interface CarRepository extends CrudRepository<Car, Long> {
+public interface CarRepository extends BasicRepository<Car, Long> {
 
   List<Car> findByType(CarType type);
 
@@ -20,7 +20,7 @@ public interface CarRepository extends CrudRepository<Car, Long> {
 }
 ----
 
-In the above example, we have a `CarRepository` interface that extends the `CrudRepository` interface provided by Jakarta EE Data. The `CrudRepository` interface offers a set of generic CRUD (Create, Read, Update, Delete) operations for entities.
+In the above example, we have a `CarRepository` interface that extends the `BasicRepository` interface provided by Jakarta EE Data. The `BasicRepository` interface offers a set of basic operations for entities.
 
 By annotating the `CarRepository` interface with `@Repository`, we indicate that it is a repository component managed by the Jakarta EE Data framework. It allows the Jakarta Data provider to automatically generate the necessary implementations for the defined methods, saving us from writing boilerplate code.
 

spec/src/main/asciidoc/portability.asciidoc

@@ -8,7 +8,7 @@ All functionality defined by Jakarta Data must be supported when using relationa
 
 1. **Support for Jakarta Persistence Annotations:** Jakarta Data, when used in conjunction with a Jakarta Persistence provider, ensures comprehensive support for all Jakarta Persistence entity annotations. This support covers a wide range of functionality, including entity definitions, primary keys, and relationships.
 
-2. **Built-In Repositories:** Jakarta Data's built-in repositories, such as `PageableRepository` and `CrudRepository`, are designed to offer consistent and well-defined methods compatible with relational databases. Developers can rely on these repositories to perform common data access tasks.
+2. **Built-In Repositories:** Jakarta Data's built-in repositories, such as `PageableRepository` and `BasicRepository`, are designed to offer consistent and well-defined methods compatible with relational databases. Developers can rely on these repositories to perform common data access tasks.
 
 3. **Query Methods:** Jakarta Data's support for query methods, including pagination, ordering, and limiting, is designed to work seamlessly with relational databases.
 
@@ -20,17 +20,17 @@ Portability in Jakarta Data extends to various NoSQL databases, each presenting
 
 ==== Key-Value Databases
 
-Key-value databases resemble dictionaries or Maps in Java, where data is primarily accessed using a key. In such databases, queries unrelated to keys are typically limited. To ensure a minimum level of support, Jakarta Data mandates the implementation of CrudRepository built-in methods that require an identifier or a key. However, the deleteAll and count methods are not required. Methods relying on complex queries, which are defined as queries that do not use the Key or identifier, raise `java.lang.UnsupportedOperationException` due to the fundamental nature of key-value databases.
+Key-value databases resemble dictionaries or Maps in Java, where data is primarily accessed using a key. In such databases, queries unrelated to keys are typically limited. To ensure a minimum level of support, Jakarta Data mandates the implementation of `BasicRepository` built-in methods that require an identifier or a key. However, the deleteAll and count methods are not required. Methods relying on complex queries, which are defined as queries that do not use the Key or identifier, raise `java.lang.UnsupportedOperationException` due to the fundamental nature of key-value databases.
 
 IMPORTANT: For any NoSQL database type not covered here, such as time series databases, the Key-value support serves as the minimum required level of compatibility.
 
 ==== Wide-Column Databases
 
-Wide-column databases offer more query flexibility, even allowing the use of secondary indexes, albeit potentially impacting performance. When interacting with wide-column databases, Jakarta Data requires the implementation of the CrudRepository along with all of its methods, including query by method. However, developers should be mindful that certain query keywords, such as "And" or "Or," may not be universally supported in these databases. The full set of required keywords is documented in the section "Query Methods Keywords".
+Wide-column databases offer more query flexibility, even allowing the use of secondary indexes, albeit potentially impacting performance. When interacting with wide-column databases, Jakarta Data requires the implementation of the `BasicRepository` along with all of its methods, including query by method. However, developers should be mindful that certain query keywords, such as "And" or "Or," may not be universally supported in these databases. The full set of required keywords is documented in the section "Query Methods Keywords".
 
 ==== Document Databases
 
-Document databases provide query flexibility akin to relational databases, offering robust query capabilities. They encourage denormalization for performance optimization. When interfacing with document databases, Jakarta Data goes a step further by supporting both built-in repositories: CrudRepository and PageableRepository. Additionally, method by query is implemented, though developers should be aware that some keywords may not be universally supported.  The full set of required keywords is documented in the section "Query Methods Keywords".
+Document databases provide query flexibility akin to relational databases, offering robust query capabilities. They encourage denormalization for performance optimization. When interfacing with document databases, Jakarta Data goes a step further by supporting both built-in repositories: `BasicRepository` and `PageableRepository`. Additionally, method by query is implemented, though developers should be aware that some keywords may not be universally supported.  The full set of required keywords is documented in the section "Query Methods Keywords".
 
 These portability considerations reflect Jakarta Data's commitment to providing a consistent data access experience across diverse NoSQL database types. While specific capabilities and query support may vary, Jakarta Data aims to simplify data access, promoting flexibility and compatibility in NoSQL database interactions.
 
@@ -40,4 +40,4 @@ A Graph database, a specialized NoSQL variant, excels in managing intricate data
 
 Graph databases excel at answering queries that return rows containing flat objects, collections, or a combination of flat objects and connections. However, portability is only guaranteed when mapping rows to classes, and when queries specified via annotations or other supported means are used. It should be noted that queries derived from keywords and combinations of mapped classes/properties will be translated into vendor-specific queries.
 
-It's important to note that in Jakarta Data the Graph database supports both built-in repositories: CrudRepository and PageableRepository. Additionally, query-by-method is implemented, though developers should be aware that some keywords may not be universally supported. The full set of required keywords is documented in the section "Query Methods Keywords."
+It's important to note that in Jakarta Data the Graph database supports both built-in repositories: `BasicRepository` and `PageableRepository`. Additionally, query-by-method is implemented, though developers should be aware that some keywords may not be universally supported. The full set of required keywords is documented in the section "Query Methods Keywords."

spec/src/main/asciidoc/repository.asciidoc

@@ -64,9 +64,9 @@ The parent interface at the root of the hierarchy of built-in interfaces is `Dat
                                   ^
                                   |
                                   |
-                          +----------------+
-                          | CrudRepository | 
-                          +----------------+ 
+                          +-----------------+
+                          | BasicRepository |
+                          +-----------------+
                                   ^
                                   |
                                   |
@@ -76,8 +76,8 @@ The parent interface at the root of the hierarchy of built-in interfaces is `Dat
 ....
 
 
-* Interface with generic CRUD operations on a repository for a specific type. This one we can see more often on several Java implementations.
-* Interface with generic CRUD operations using the pagination feature.
+* Interface with basic operations on a repository for a specific type. This one we can see more often on several Java implementations.
+* Interface with basic operations using the pagination feature.
 
 From the Java developer perspective, create an interface that is annotated with the `@Repository` annotation and optionally extends one of the built-in repository interfaces.
 
@@ -86,7 +86,7 @@ So, given a `Product` entity where the ID is a `long` type, the repository would
 [source,java]
 ----
 @Repository
-public interface ProductRepository extends CrudRepository<Product, Long> {
+public interface ProductRepository extends BasicRepository<Product, Long> {
 
 }
 ----
@@ -97,7 +97,7 @@ There is no nomenclature restriction to make mandatory the `Repository` suffix.
 [source,java]
 ----
 @Repository
-public interface Garage extends CrudRepository<Car, String> {
+public interface Garage extends BasicRepository<Car, String> {
 
 }
 ----
@@ -399,7 +399,7 @@ The `@Query` annotation supports providing a search expression as a String. The
 [source,java]
 ----
 @Repository
-public interface ProductRepository extends CrudRepository<Product, Long> {
+public interface ProductRepository extends BasicRepository<Product, Long> {
   @Query("SELECT p FROM Products p WHERE p.name=?1")  // example in JPQL
   Optional<Product> findByName(String name);
 }
@@ -410,7 +410,7 @@ Jakarta Data also includes the `@Param` annotation to define a binder annotation
 [source,java]
 ----
 @Repository
-public interface ProductRepository extends CrudRepository<Product, Long> {
+public interface ProductRepository extends BasicRepository<Product, Long> {
   @Query("SELECT p FROM Products p WHERE p.name=:name")  // example in JPQL
   Optional<Product> findByName(@Param("name") String name);
 }
@@ -424,7 +424,7 @@ The Query by method mechanism allows for creating query commands by naming conve
 [source,java]
 ----
 @Repository
-public interface ProductRepository extends CrudRepository<Product, Long> {
+public interface ProductRepository extends BasicRepository<Product, Long> {
 
   List<Product> findByName(String name);
 
@@ -498,7 +498,7 @@ Assume an Order entity has an Address with a ZipCode. In that case, the access i
 [source,java]
 ----
 @Repository
-public interface OrderRepository extends CrudRepository<Order, Long> {
+public interface OrderRepository extends BasicRepository<Order, Long> {
 
   @Query("SELECT order FROM Order order WHERE order.address.zipCode=?1")
   List<Order> withZipCode(ZipCode zipCode);
@@ -788,7 +788,7 @@ Example repository methods that use Query by Parameters:
 [source,java]
 ----
 @Repository
-public interface ProductRepository extends CrudRepository<Product, Long> {
+public interface ProductRepository extends BasicRepository<Product, Long> {
 
   // Assumes that the Product entity has attributes: yearProduced
   List<Product> findMadeIn(int yearProduced, Sort... sorts);
@@ -814,7 +814,7 @@ Jakarta Data recognizes, when specified on a repository method after the query p
 [source,java]
 ----
 @Repository
-public interface ProductRepository extends CrudRepository<Product, Long> {
+public interface ProductRepository extends BasicRepository<Product, Long> {
 
   List<Product> findByName(String name, Pageable pageable);
 
@@ -932,7 +932,7 @@ For example,
 [source,java]
 ----
 @Repository
-public interface CustomerRepository extends CrudRepository<Customer, Long> {
+public interface CustomerRepository extends BasicRepository<Customer, Long> {
   KeysetAwareSlice<Customer> findByZipcodeOrderByLastNameAscFirstNameAscIdAsc(
                                  int zipcode, Pageable pageable);
 }
@@ -1009,7 +1009,7 @@ Here is an example where an application uses `@Query` to provide a partial query
 [source,java]
 ----
 @Repository
-public interface CustomerRepository extends CrudRepository<Customer, Long> {
+public interface CustomerRepository extends BasicRepository<Customer, Long> {
   @Query("SELECT o FROM Customer o WHERE (o.totalSpent / o.totalPurchases > ?1)")
   KeysetAwareSlice<Customer> withAveragePurchaseAbove(float minimum, Pageable pagination);
 }

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

@@ -111,6 +111,26 @@ public void ensureCharacterPrepopulation() {
         assertTrue(characters.findByNumericValue(1).get().isControl());
     }
 
+    @Assertion(id = "133",
+            strategy = "Use a repository that inherits from BasicRepository and adds some methods of its own. " +
+                       "Use both built-in methods and the additional methods.")
+    public void testBasicRepository() {
+        assertEquals(false, numbers.existsById(0L));
+        assertEquals(true, numbers.existsById(80L));
+
+        Stream<NaturalNumber> found;
+        found = numbers.findByIdIn(List.of(70L, 40L, -20L, 10L));
+        assertEquals(List.of(10L, 40L, 70L),
+                     found.map(NaturalNumber::getId).sorted().collect(Collectors.toList()));
+
+        found = numbers.findByIdBetween(50L, 59L, Sort.asc("numType"));
+        List<Long> list = found.map(NaturalNumber::getId).collect(Collectors.toList());
+        assertEquals(Set.of(53L, 59L), // first 2 must be primes
+                     new TreeSet<>(list.subList(0, 2)));
+        assertEquals(Set.of(50L, 51L, 52L, 54L, 55L, 56L, 57L, 58L), // the remaining 8 are composite numbers
+                     new TreeSet<>(list.subList(2, 10)));
+    }
+
     @Assertion(id = "133", strategy = "Request a Page higher than the final Page, expecting an empty Page with 0 results.")
     public void testBeyondFinalPage() {
         Pageable sixth = Pageable.ofPage(6).sortBy(Sort.asc("numericValue")).size(10);
@@ -179,26 +199,6 @@ public void testContainsInString() {
                      found.stream().map(AsciiCharacter::getHexadecimal).sorted().toList());
     }
 
-    @Assertion(id = "133",
-               strategy = "Use a repository that inherits from CrudRepository and adds some methods of its own. " +
-                          "Use both built-in methods and the additional methods.")
-    public void testCrudRepository() {
-        assertEquals(false, numbers.existsById(0L));
-        assertEquals(true, numbers.existsById(80L));
-
-        Stream<NaturalNumber> found;
-        found = numbers.findByIdIn(List.of(70L, 40L, -20L, 10L));
-        assertEquals(List.of(10L, 40L, 70L),
-                     found.map(NaturalNumber::getId).sorted().collect(Collectors.toList()));
-
-        found = numbers.findByIdBetween(50L, 59L, Sort.asc("numType"));
-        List<Long> list = found.map(NaturalNumber::getId).collect(Collectors.toList());
-        assertEquals(Set.of(53L, 59L), // first 2 must be primes
-                     new TreeSet<>(list.subList(0, 2)));
-        assertEquals(Set.of(50L, 51L, 52L, 54L, 55L, 56L, 57L, 58L), // the remaining 8 are composite numbers
-                     new TreeSet<>(list.subList(2, 10)));
-    }
-
     @Assertion(id = "133", strategy = "Use a repository that inherits from DataRepository and defines all of its own methods.")
     public void testDataRepository() {
         AsciiCharacter del = characters.findByIsControlTrueAndNumericValueBetween(33, 127);