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-1630) .Net: Create LINQ adapter for queries.
Date Tue, 01 Mar 2016 11:39:18 GMT

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

Pavel Tupitsyn edited comment on IGNITE-1630 at 3/1/16 11:38 AM:
-----------------------------------------------------------------

1) Done
2) Done (except fields queries, where this is not possible)
3) Allows to specify Java type name to be used in SQL index, if the user wants to override
default mapping
4) Improves performance of the fields query. Instead allocating a List<object> and then
unboxing the values from it, we can read fields directly as specific types.
LINQ provider uses this method when doing fields queries. I'd like to avoid adding another
InternalsVisibleTo for LINQ project, so this has to be on public API. 

And by itself, this method is not only faster than old one, but also more usable.
{code}cache.QueryFields((r,c)=>new MyClass(r.ReadInt(), r.ReadString())){code} is much
better than working with untyped list.

5) Ignite SQL has reserved "_key" and "_val" field names to query cache entry key or value
as a whole. LINQ provider looks at [QuerySqlField] attributes to generate field names. 
6) This is just a placeholder. It is much better than "Console.WriteLine" scattered all over
the codebase that we had before. There are separate tasks for logging, I just did not want
to add more WriteLine calls.
7) AsQueryable is an existing extension method in System.Linq.Queryable. Our method should
stand out, because it implies a totally different mechanism underneath.
8) Yes, we do, it provides a way to eliminate LINQ translation overhead. The design is the
same as in Entity Framework and will be familiar to the users. https://msdn.microsoft.com/en-us/library/system.data.linq.compiledquery(v=vs.110).aspx
9) Yes, but ICache is generic. We can't return original cache instance in a non-generic interface.

10) This name is from Entity Framework: https://msdn.microsoft.com/en-us/library/system.data.objects.objectquery.totracestring(v=vs.110).aspx
11) Any query that originates from our ToCacheQueryable can be cast to this interface to obtain
resulting SQL and other things. Again, same thing as in EF. LINQ is just a set of extension
methods, they all return IQueryable, so there is no way to operate on our own interface.
12) This interface is for query provider implementers, not for users. Users operate solely
on IQueryable.


was (Author: ptupitsyn):
1) Done
2) Done (except fields queries, where this is not possible)
3) Allows to specify Java type name to be used in SQL index, if the user wants to override
default mapping
4) Improves performance of the fields query. Instead allocating a List<object> and then
unboxing the values from it, we can read fields directly as specific types.
LINQ provider uses this method when doing fields queries. I'd like to avoid adding another
InternalsVisibleTo for LINQ project, so this has to be on public API. 

And by itself, this method is not only faster than old one, but also more usable.
{code}cache.QueryFields((r,c)=>new MyClass(r.ReadInt(), r.ReadString())){code} is much
better than working with untyped list.

5) Ignite SQL has reserved "_key" and "_val" field names to query cache entry key or value
as a whole. LINQ provider looks at [QuerySqlField] attributes to generate field names. 
6) This is just a placeholder. It is much better than "Console.WriteLine" scattered all over
the codebase that we had before. There are separate tasks for logging, I just did not want
to add more WriteLine calls.
7) AsQueryable is an existing extension method in System.Linq.Queryable. Our method should
stand out, because it implies a totally different mechanism underneath.
8) Yes, we do, it provides a way to eliminate LINQ translation overhead. The design is the
same as in Entity Framework and will be familiar to the users. https://msdn.microsoft.com/en-us/library/system.data.linq.compiledquery(v=vs.110).aspx
9) Yes, but ICache is generic. We can't return original cache instance in a non-generic interface.

10) This name is from Entity Framework: https://msdn.microsoft.com/en-us/library/system.data.objects.objectquery.totracestring(v=vs.110).aspx
11) Any query that originates from our ToCacheQueryable can be cast to this interface to obtain
resulting SQL and other things. Again, same thing as in EF. LINQ is just a set of extension
methods, they all return IQueryable, so there is no way to operate on our own interface.

> .Net: Create LINQ adapter for queries.
> --------------------------------------
>
>                 Key: IGNITE-1630
>                 URL: https://issues.apache.org/jira/browse/IGNITE-1630
>             Project: Ignite
>          Issue Type: Task
>          Components: platforms
>    Affects Versions: ignite-1.4
>            Reporter: Vladimir Ozerov
>            Assignee: Pavel Tupitsyn
>            Priority: Critical
>             Fix For: 1.6
>
>
> SQL queries are one of the most frequently used features in data grids. And .Net comes
with a very nice LINQ concept. 
> * LINQ provider should come in a separate assembly
> * Make sure that assembly is included in binary distribution



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

Mime
View raw message