Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.apache.org
MIME-Version: 1.0
From: Eduard Shangareev <eduard.shangareev@gmail.com>
Date: Thu, 4 Aug 2016 14:23:59 +0300
Message-ID: <CAKnekaT5Nrfdx50M_E9OM8vatpnNy8RUVRSUSgRQ-RhH0K5uyw@mail.gmail.com>
Subject: IGNITE-1192 Implementation (Integration with Spring Data)
To: dev@ignite.apache.org
Content-Type: multipart/alternative; boundary=001a1144451ab81d3505393d2fc7
archived-at: Thu, 04 Aug 2016 11:24:06 -0000

--001a1144451ab81d3505393d2fc7
Content-Type: text/plain; charset=UTF-8

Guys, greetings!

I am working on Spring Data integration. There are two ways how we can use
Spring Data:
1. generating layer for Ignite usage;
2. using existing Spring Data configuration for persistence (Spring Data
JPA, for example, or Mongo).

I am sure that we should concentrate on  first part because Ignite already
has no problem with persistence.

Main feature Spring Data provides - Repository concept, a user just defines
some interface for entity access and spring data framework automatically
generates CRUD/query methods.
And I am going to use Ignite via SQL-layer.

Documentation of spring-data-commons (which I will use to refer):
http://docs.spring.io/spring-data/data-commons/docs/current/reference/html/


The list of features and problems:
1. Support Java8 (Streams, CompletableFuture);
2. Async query results (Future, ListenableFuture, CompletableFuture as
return type);
3. List of supported query return types (Appendix D);
4. List of supported query keywords (Appendix C);
5. Support of Pageable, Sort as method parameters;
6. Transaction support;
7. Lock support;
8. Querydsl support;
9. Query by example (QbE) support;
10. Enabling auto-cache configuration/creation by repository interface;
11. Support entities with keys.
12. Explicit query support (user-defined).
13. Support other Ignite capabilities.

Well, we should decide what we want to see in first version of spring-data
support.

Below I will try to explain paragraphs in more detail.

1. Nothing to explain. I think it can wait.

2. We already have async API, so there should be no problem to support this.

3. It is connected with 1 and 5. I think we will not
support GeoResult, GeoResults, GeoPage, guava's Optional.

4. I think it should match our SQL-capabilities

5. As I know we support already LIMIT, OFFSET, ORDER BY. I am wondered
by Page return type (should we support it?).

6. There is no support in sql now.

7. We can do it by adding extra methods to IgniteRepository.

8. I haven't seen what it is but looks interesting.
9. See p.9.

10. At least we should determine in some way which cache we should use to
execute queries. In the prototype I am using own annotation for it.
But maybe we should be able to create cache configuration from scratch only
by repository interface (with the usage of own annotations).


11. By default, spring data assumes that entity contains keys. But it is
not our case. We can throw UnsupportedException when methods with an only
entity are used as method-parameter, or check that there is a field with
@Id annotation.
Also, there is separate module 'Spring Data Key Value' which provides some
infrastructure for key/value storage integration (
https://github.com/spring-projects/spring-data-keyvalue). Need check if it
makes sense to use it for Ignite integration.

12. In the prototype I have defined annotation @Query. The user can
annotate query-method with it and we will use it to query cache.

13. There are many features in Ignite. Which should we support in this
integration?

Also, you can look on Semen's comment in ticket for repository example:
https://issues.apache.org/jira/browse/IGNITE-1192?focusedCommentId=15398164&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15398164

Any thoughts, opinions?

--001a1144451ab81d3505393d2fc7--