ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Tupitsyn (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (IGNITE-1896) .Net: Improve query API
Date Fri, 13 Nov 2015 08:45:10 GMT

    [ https://issues.apache.org/jira/browse/IGNITE-1896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15003723#comment-15003723
] 

Pavel  Tupitsyn edited comment on IGNITE-1896 at 11/13/15 8:44 AM:
-------------------------------------------------------------------

1) I don't propose to remove current method altogether, I propose to complement it with more
usable methods. If arguments are added, API won't be broken. We can keep simple methods for
simple scenarios, and current approach for higher customization

2) There is a problem. When you use a dictionary, you have to specify generic arguments only
once, in constructor. Then you never have to do it again, no chance to make a mistake:
{code}
var dict = new Dictionary<int, Person>();
dict[1] = new Person();  // No generic arguments
var person = dict[1];  // No generic arguments
{code}

Same with put/get in our cache, no problem there.
But with queries:
{code}
var cache = ignite.GetCache<int, Person>();  // generic arguments specified once, this
is fine
var person = cache.Get(1);  // no generic arguments, good

// Why do we force user to specify typeof(Person)? Cache already knows this type. 
// And there will be an exception if the user specifies wrong type
var sqlQuery = cache.Query(new SqlQuery(typeof (Person), "Age > ?", 5));  
// Much cleaner, isn't it?
var sqlQuery = cache.SqlQuery("Age > ?", 5)

// Again, why do we force user to type so much? Generic arguments are known.
var scanQuery = cache.Query(new ScanQuery<int, Person>());
// Compare to:
var scanQuery = cache.ScanQuery();
{code}

Same issue we had with GetFuture. Too much typing, prone to errors, makes refactoring hard.


was (Author: ptupitsyn):
1) I don't propose to remove current method altogether, I propose to complement it with more
usable methods. If arguments are added, API won't be broken. We can keep simple methods for
simple scenarios, and current approach for higher customization

2) There is a problem. When you use a dictionary, you have to specify generic arguments only
once, in constructor. Then you never have to do it again:
{code}
var dict = new Dictionary<int, Person>();
dict[1] = new Person();  // No generic arguments
var person = dict[1];  // No generic arguments
{code}

Same with put/get in our cache, no problem there.
But with queries:
{code}
var cache = ignite.GetCache<int, Person>();  // generic arguments specified once, this
is fine
var person = cache.Get(1);  // no generic arguments, good

// Why do we force user to specify typeof(Person)? Cache already knows this type. 
// And there will be an exception if the user specifies wrong type
var sqlQuery = cache.Query(new SqlQuery(typeof (Person), "Age > ?", 5));  
// Much cleaner, isn't it?
var sqlQuery = cache.SqlQuery("Age > ?", 5)

// Again, why do we force user to type so much? Generic arguments are known.
var scanQuery = cache.Query(new ScanQuery<int, Person>());
// Compare to:
var scanQuery = cache.ScanQuery();
{code}

Same issue we had with GetFuture. Too much typing, prone to errors, makes refactoring hard.

> .Net: Improve query API
> -----------------------
>
>                 Key: IGNITE-1896
>                 URL: https://issues.apache.org/jira/browse/IGNITE-1896
>             Project: Ignite
>          Issue Type: Improvement
>          Components: interop
>    Affects Versions: 1.1.4
>            Reporter: Pavel  Tupitsyn
>            Assignee: Pavel  Tupitsyn
>             Fix For: 1.5
>
>
> Current API is very clumsy.
> Cache is generic, however we require the user to specify query type explicitly.
> There are cases when query type is a string and/or is different from current cache generic
type, so the current API has to be kept.
> However, we should provide simple methods with generic inference:
> {code}
>         IQueryCursor<ICacheEntry<TK, TV>> ScanQuery(ICacheEntryFilter<TK,
TV> filter);
>         IQueryCursor<ICacheEntry<TK, TV>> SqlQuery(string sql, params object[]
args);
>         IQueryCursor<ICacheEntry<TK, TV>> SqlQuery(string sql, bool local,
params object[] args);
>         IQueryCursor<ICacheEntry<TK, TV>> TextQuery(string text);
>         IQueryCursor<ICacheEntry<TK, TV>> TextQuery(string text, bool local);
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message