43. Repositories - JPA
<jpa:repositories base-package="com.acme.repositories" />
public interface PersonRepository extends Repository<Person, BigInteger>
{
// Finder for a single entity
Person findByEmailAddress(String emailAddress);
// Finder for multiple entities
List<Person> findByLastnameLike(String lastname);
// Finder with pagination
Page<Person> findByFirstnameLike(String firstname, Pageable page);
}
43
44. Repositories - MongoDB
public interface PersonRepository extends Repository<Person, BigInteger>
{
// Finder for a single entity
Person findByEmailAddress(String emailAddress);
// Finder for multiple entities
List<Person> findByLastnameLike(String lastname);
// Finder with pagination
Page<Person> findByFirstnameLike(String firstname, Pageable page);
// Geospatial queries
List<Person> findByLocationNear(Point location, Distance distance);
GeoResults<Person> findByLocationNear(Point location);
}
44
45. Repositories - MongoDB
<mongo:repositories base-package="com.acme.repositories" />
@Component
public class MyClient {
@Autowired
private PersonRepository repository;
public List<Person> doSomething() {
Point point = new Point(43.7, 48.8);
Distance distance = new Distance(200, Metrics.KILOMETERS);
return repository.findByLocationNear(point, distance);
}
}
45
46. Repositories - Neo4J
interface PersonRepository extends GraphRepository<Person, Long>
// Finder for a single entity
Person findByEmailAddress(String emailAddress);
// Finder for multiple entities
List<Person> findByLastnameLike(String lastname);
// Finder with pagination
Page<Person> findByFirstnameLike(String firstname, Pageable page);
@Query("start person = Person(id = *) " +
"match person-[:colleagues]->colleague where " +
"colleague.firstname = {name}")
List<Person> getPersonsWithColleaguesName(
@Param("name") Movie m);
}
46
Traditional approach to data storage\nDeveloper&#x2018;s point of view\n
Well known, solid\nAdmins know how to administer it\nProblems? Challenges?\nTwo main drivers: Cloud and Datastructures\n
New challenges in deployment platforms\nCloudFoundry\n
Consistency requirements -> hard to scale -> CAP\nSQLFire\n\n
Transactions as consistency switch\nOrganize data differently\n
Object-relational-mismatch\nInheritance, Trees (Nested Set?), Networks\n
Huge variety of APIs\n
\n
\n
\n
\n
Starring today&#x2026; MongoDB\n
\n
\n
\n
\n
\n
\n
\n
Hard to choose\nDifferent APIs all over the place\n
\n
\n
Umbrella projects for Data Access 2.0\n
\n
Variety of stores supported (or planned)\n
Key/Value stores\n
Document stores\n
Other ones (graph)\n
\n
- Spring already provides support for JDBC, JPA, Hibernate etc.\n- add functionality on top of that\n- leverage well known Spring concepts\n - DI, AOP, Spring namespaces, JMX\n
POJO based mapping\nAnnotation based mapping (Morphia and beyond)\n- Persistence constructor\n- (deeply nested) Generics\n- DBRef -> embeds by default\n- Document -> specify collections\n
Eliminate boilerplate code\n\n- interface-only approach\n- finder methods\n- annotations for query tweaking\n- QueryDsl integration for type safe queries\n