Details
-
Improvement
-
Status: Open
-
Major
-
Resolution: Unresolved
-
1.9 M1 (Ingalls), 1.0.0.APACHE-GEODE-INCUBATING-M2
-
Spring (Data GemFire/Data Geode) + Pivotal GemFire | Apache Geode.
-
Kay RC1, Kay RC3, Kay GA, Kay SR1, Lovelace M1, Lovelace M2 / M3, Lovelace RC1, Lovelace GA, Lovelace SR1, Moore RC1, Moore RC2, Moore SR1, Moore SR2, Neumann M3, Neumann M4, Neumann RC1, 2020.0.0 - Ockham M1, 2020.0.0 - Ockham RC2, 2021.0.0 - Pascal M1
Description
This improvement will track the development of Repository query method projections.
Typically, SD [GemFire] Repositories are tied to a single application domain object type. However, query methods, whether by convention or annotated with @Query, can return a custom type containing a subset of the properties from the actual domain object type itself (the "projection").
For example, I may have defined a Customer like so...
@Region("Contacts") class Contact { Address address; Customer customer; PhoneNumber phoneNumber; String email; ... }
Any one of the composed types (e.g. Customer) can be arbitrarily complex. Currently, the corresponding [CRUD] Repository might look like the following containing a query to find all Contacts in a particular city/state.
interface ContactRepository extends CrudRepository<Customer, Long> { List<Contact> findByAddressCityAndAddressState(State state, String city); }
Depending on the application view, the user may only want a subset of the data returned from the query to project into the view. In other words, rather than returning the entire Contact, the user may want to only find all Customers by first and last name with phone number in a given city/state.
For example...
<code:java}
interface ContactRepository extends CrudRepository<Customer, Long>
With the corresponding, given CustomerView...
class CustomerView { PhoneNumber phoneNumber; String accountNumber; String firstName; String lastName; }
Repository query projection support effectively allows the user to redefine their query method with the data of interests.