[jira] [Created] (IGNITE-2449) Project structure content is not equal the real content of zip file

2016-01-25 Thread Pavel Konstantinov (JIRA)
Pavel Konstantinov created IGNITE-2449:
--

 Summary: Project structure content is not equal the real content 
of zip file
 Key: IGNITE-2449
 URL: https://issues.apache.org/jira/browse/IGNITE-2449
 Project: Ignite
  Issue Type: Sub-task
Reporter: Pavel Konstantinov


Please see attachment:
1) unequal sorting
2) unequal content - 'model' folder in 'project structure' should be on top 
level. 



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


[GitHub] ignite pull request: Fixed ignite-2231

2016-01-25 Thread wmz7year
GitHub user wmz7year opened a pull request:

https://github.com/apache/ignite/pull/425

Fixed ignite-2231

Remove check hasValueUnlocked when addEvent.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/wmz7year/ignite ignite-2231

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/425.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #425


commit a02d7c88290de5caa9cc50460293266237685ab7
Author: wmz7year 
Date:   2016-01-26T03:06:33Z

Fixed ignite-2231

Remove check hasValueUnlocked when addEvent.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[GitHub] ignite pull request: Ignite 2191 Not to merge

2016-01-25 Thread ashutakGG
GitHub user ashutakGG opened a pull request:

https://github.com/apache/ignite/pull/424

Ignite 2191 Not to merge



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/ashutakGG/incubator-ignite ignite-2191-tmp2

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/424.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #424


commit fa70b383e4ccad00482d74a796c8c1dc2041448a
Author: ashutak 
Date:   2016-01-12T14:56:57Z

ignite-2191:

commit 5804b2d5c9fb7dc7bb7061743603eaa9c5abae2e
Author: ashutak 
Date:   2016-01-12T17:22:13Z

ignite-2191: fix tests

commit 9e6682c975e56f845f20d60b04374106d5f77bcb
Author: ashutak 
Date:   2016-01-13T11:07:11Z

Merge branch 'master' into ignite-2191-simple-name

commit fbfb8a18de423d5cdcc91458ffede4ef34f819e6
Author: ashutak 
Date:   2016-01-13T13:15:00Z

ignite-2191: fix tests

commit d2696165cbc6ba90657395fb52a96ba325989c64
Author: ashutak 
Date:   2016-01-13T15:47:37Z

ignite-2191: add BinaryPlatformIdMapper.java

commit 31edbb051d957a51bdd30a0a4a63b24e8d556a80
Author: ashutak 
Date:   2016-01-14T15:31:16Z

ignite-2191: resolve id mapper and add tests

commit 16faa298010df8e31af87b9bae517f3c3541b180
Author: ashutak 
Date:   2016-01-15T09:21:29Z

ignite-2191: check binary configuration.

commit 17012aeb99bd6d5ceb7f1c5b71d17c7095131e61
Author: ashutak 
Date:   2016-01-15T10:58:44Z

ignite-2191: minor fix

commit 160c8c395d38460401e6e2cb3798a55aafc6a16d
Author: ashutak 
Date:   2016-01-15T11:06:26Z

ignite-2191: revert resolveIdMapper according to configuration

commit 20aab083891b60dd88c84ce31f19a41fafc42a30
Author: ashutak 
Date:   2016-01-15T14:57:23Z

ignite-2191: Fixed and added BinaryObjectBuilder*IdMapperSelfTest

commit 6f6c43e24cf41dd8f0739508445d842735f840ca
Author: ashutak 
Date:   2016-01-15T15:03:15Z

ignite-2191: Move Id mappers to public package

commit edbfc3c984c937358e8179dd88a7ff88992ff6ae
Author: ashutak 
Date:   2016-01-15T15:19:13Z

Merge branch 'master' into ignite-2191-simple-name

commit d4fea6bc8fa5c2a030973646ca4b154cfeb3597b
Author: ashutak 
Date:   2016-01-15T15:48:34Z

ignite-2191: Self review.

commit 6f33505a0e9d3888506d880f71159b65f9f811fb
Author: ashutak 
Date:   2016-01-15T16:26:56Z

ignite-2191: Fix .Net tests.

commit 3584214dfda9feeb14d7f79f4fa81122db4ef84a
Author: ashutak 
Date:   2016-01-15T16:32:56Z

ignite-2191: Move wrapper to internals and add public constructors

commit 952d697cef46df8d45b7f134c453049d8291a27b
Author: ashutak 
Date:   2016-01-15T17:52:13Z

ignite-2191: wildcars tests and mappers tests

commit d524499545c07a8f13073375fbf846575b2821cf
Author: ashutak 
Date:   2016-01-15T18:24:33Z

ignite-2191: fix tests

commit f24a314a7f51e77002b47df728d1ca3681bc86a3
Author: ashutak 
Date:   2016-01-15T18:32:49Z

ignite-2191: fix tests

commit 6f57ad450826a8d11eccd811bd3bcd0d6a5f61cf
Author: ashutak 
Date:   2016-01-18T10:24:41Z

ignite-2191: fix .Net tests

commit 4eff2cbb9a2a9b9cb1ee0539da36d60dac0845be
Author: ashutak 
Date:   2016-01-18T12:04:24Z

ignite-2191: fix .Net (set id mapper)

commit 33e5e526652d75ad94d520468a12cf2dee240425
Author: ashutak 
Date:   2016-01-18T12:58:20Z

ignite-2191: check binary cfg (since)

commit 151242f6d7718c80d464abedf8058b30dfb631bd
Author: ashutak 
Date:   2016-01-18T13:58:39Z

Merge branch 'master' into ignite-2191-simple-name

commit 2dbc9042473fd1c94726691d6b2000493f6444e5
Author: ashutak 
Date:   2016-01-18T15:02:25Z

ignite-2191: set simple name id mapper as default

commit 94c52bdcc41f431a24bd70f8f603b816a077e246
Author: ashutak 
Date:   2016-01-18T15:55:59Z

ignite-2191: fix binary tests

commit 4bd85460f4b00cde0d9636f2fc3cc1f751d2a41d
Author: ashutak 
Date:   2016-01-19T10:05:58Z

ignite-2191: fix IgniteConfiguration chaining

commit 639ff9cd8107567d126be8f32af17285381cc3f3
Author: ashutak 
Date:   2016-01-19T10:06:23Z

ignite-2191: potential fix of enum test

commit dcb6fec9017d826b4fe9bf646dc07ffe91c2d323
Author: ashutak 
Date:   2016-01-19T10:48:04Z

ignite-2191: dumpStack

commit dd23a8d32b7895cac05657aa3f8f80ee03909c01
Author: ashutak 
Date:   2016-01-19T12:40:21Z

ignite-2191: add BinaryNameMapper interface

commit 7e93913a15ab6da65aaf1e7786ac1ae31af1740c
Author: ashutak 
Date:   2016-01-19T15:52:08Z

ignite-2191: use name mapper

commit 180521b31fe4b70c9f83204d26fab07be20ecfcd
Author: ashutak 
Date:   2016-01-19T17:27:09Z

ignite-2191: fix enums




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a 

[GitHub] ignite pull request: Ignite disabled per-partition map

2016-01-25 Thread yzhdanov
GitHub user yzhdanov opened a pull request:

https://github.com/apache/ignite/pull/423

Ignite disabled per-partition map



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/yzhdanov/ignite 
ignite-disabled-perpartition-map

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/423.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #423


commit 914b365f79311e56c46ee4e214f60d60753030cc
Author: Yakov Zhdanov 
Date:   2016-01-25T18:34:43Z

fixed https://issues.apache.org/jira/browse/IGNITE-2329 + forceKeysFuture 
opts

commit 3f1ab4dac0f85729026fd06eec97e9d2e3e002fa
Author: Yakov Zhdanov 
Date:   2016-01-25T18:48:17Z

fixed https://issues.apache.org/jira/browse/IGNITE-2329 + forceKeysFuture 
opts + disabled partition map




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[GitHub] ignite pull request: fixed https://issues.apache.org/jira/browse/I...

2016-01-25 Thread yzhdanov
GitHub user yzhdanov opened a pull request:

https://github.com/apache/ignite/pull/422

fixed https://issues.apache.org/jira/browse/IGNITE-2329 + forceKeysFu…

fixed https://issues.apache.org/jira/browse/IGNITE-2329 + forceKeysFu…

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/yzhdanov/ignite ignite-gc-opts

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/422.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #422


commit 914b365f79311e56c46ee4e214f60d60753030cc
Author: Yakov Zhdanov 
Date:   2016-01-25T18:34:43Z

fixed https://issues.apache.org/jira/browse/IGNITE-2329 + forceKeysFuture 
opts




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


Re: MyBatis and Apache Ignite integration

2016-01-25 Thread Dmitriy Setrakyan
I have also added this ticket to Ignite contribute page here:
https://ignite.apache.org/community/contribute.html#pick-ticket

On Mon, Jan 25, 2016 at 8:16 AM, Denis Magda  wrote:

> HI All,
>
> I've opened an Ignite ticket with tasks description [1]
>
> Is there anyone in Apache Ignite community who is interested in this kind
> of work and will be able to complete it in the nearest couple of weeks?
>
> [1] https://issues.apache.org/jira/browse/IGNITE-2448
>
> Regards,
> Denis
>
>
> On 1/23/2016 11:28 AM, dma...@gridgain.com wrote:
>
>> Hi Eduardo,
>>
>> It's nice to hear from you! Thanks the help and details!
>>
>> Absolutely agree with you that the interface is straightforward and I
>> don't see any difficulties that can arise during its implementation.
>> I'll open an Apache Ignite JIRA ticket soon describing the integration
>> details and hope that someone from Ignite community will pick it up the
>> next week starting working on the plugin.
>>
>> As per the hosting I would host everything on MyBatis GitHub repo as it
>> is already done for other plugins and in addition would add a documentation
>> to Apache Ignite [1]. This way both MyBatis and Ignite community will be
>> aware about the integration and we don't need to host the plugin in
>> different repos.
>>
>> I've copied Ignite dev community to the discussion -
>> dev@ignite.apache.org. So please make sure that this dev list is copied
>> when you reply ;)
>>
>> If someone else from either MyBatis or Ignite community has any thoughts
>> on this topic please share.
>>
>> [1] https://apacheignite.readme.io
>>
>> Regards,
>> Denis
>>
>> On Saturday, January 23, 2016 at 12:46:08 AM UTC+3, Eduardo wrote:
>>
>> Hi Denis,
>>
>> First of all. Wellcome to the list!
>>
>> AFAIK all the cache integration plugins have been developed by
>> ourselves. The interface is quite easy so the task is usualy
>> pretty straight forward.
>>
>> I will be very happy to help with the integration! I would suggest
>> creating a new repo and work on it. Probably it will be better
>> that that someone from the Ignite project builds the plugin and we
>> provide information about how the interface works.
>>
>> Regarding the future hosting, I suppose there will be no problem
>> in hosting the new project at our home in Github but is also
>> perfect that you host it as part of the ignite project. No problem
>> at all with any option!
>>
>> Looking forward to starting! :)
>>
>> 2016-01-21 10:30 GMT+01:00 >:
>>
>>
>> Hi MyBatis community!
>>
>> I'm a committer and PMC of Apache Ignite [1] project and
>> writing to you on behalf of our community (+ CC-ed) to discuss
>> an integration between our projects that should be useful for
>> both sides.
>>
>> In short, Apache Ignite is a high-performance, integrated and
>> distributed in-memory platform for computing and transacting
>> on large-scale data sets in real-time, orders of magnitude
>> faster than possible with traditional disk-based or flash
>> technologies.
>> Inside of our community we see a growing interest in a field
>> of usage MyBatis along with Apache Ignite. There are use cases
>> when developers/users wants to use Apache Ignite as MyBatis
>> second level cache. Since such an interest is growing
>> constantly we think that it's a right time to make this happen.
>>
>> As I see MyBatis already supports second level cache for
>> Redis, Hazelcast and Ehcache.
>>
>> How do you usually add such components? Were they added by
>> MyBatis guys or were developed by guys from Redis, Hazelcast,
>> etc.?
>>
>> [1] https://ignite.apache.org/
>>
>> Regards,
>> Denis
>>
>> -- You received this message because you are subscribed
>> to the
>> Google Groups "mybatis-user" group.
>> To unsubscribe from this group and stop receiving emails from
>> it, send an email to mybatis-user...@googlegroups.com
>> .
>> For more options, visit https://groups.google.com/d/optout
>> .
>>
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "mybatis-user" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/mybatis-user/CxSqG1dprm4/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> mybatis-user+unsubscr...@googlegroups.com > mybatis-user+unsubscr...@googlegroups.com>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>


Re: Ignite Readme.IO UX issue

2016-01-25 Thread Dmitriy Setrakyan
Hadoop/IGFS documentation is being refactored right now. Could be a side
effect of what you were observing.

Btw, everyone with login to readme can file a support issue. However, I
would not do it yet, while Prachi is still working on refactoring.

D.

On Mon, Jan 25, 2016 at 6:51 AM, Alexey Kuznetsov 
wrote:

> Hi!
>
> Does someone knows it is possible or not to "sync" left pane with
> documentation categories and right pane with content of some selected
> category?
>
> For example: https://apacheignite.readme.io/docs/igfs
>
> I see some IGFS documentation, but on the left pane I do not see selected
> category "IGFS", I need to scroll down. This is very annoying when you are
> reading several related topics - you need to scroll every time.
>
> As I know readme.io is a kind of CMS, so who knows how to open an issue
> for
> them?
> Do they have any kind of JIRA / mail list / support forum?
>
> --
> Alexey Kuznetsov
> GridGain Systems
> www.gridgain.com
>


Re: Ignite SQL syntax: key fields, scalars, nested fields

2016-01-25 Thread Sergi Vladykin
See inline

2016-01-25 19:16 GMT+03:00 Pavel Tupitsyn :

> Thank you Sergi, more questions:
>
> - How do I get the result of an aggregate? Via Fields query? Will it always
> be a single value, or a value per node?
>

Yes, using fields query. Supported aggregates must work correctly across
cluster.


> - If field names are flattened, what are QueryEntity.aliases for? Javadoc
> talks about dot notation, I thought it is for nested fields.
>

Exactly aliases are needed to resolve duplication cases. For example you
have entity Person it has field `child` which has field `age` and field
`car` which has field `age` as well. You can specify in config that
"child.age" must have SQL alias "child_age" and "car.age" will have alias
"car_age". Obviously you can't use `car.age` notation in sql as is.


> - What is the purpose of SqlQuery.type? We use simple name of the class for
> it everywhere. Does it relate to type id mapping somehow?
>

Sometimes (when we work with binary objects) we don't have classes at all.


> - I tried to use _key/_val aliases and could not get them to work:
>* "_val.Age > ?": Failed to parse query: SELECT
> "cache".QueryPerson._key, "cache".QueryPerson._val FROM "cache".QueryPerson
> WHERE _val.Age > ?
>

There are no dot notation in SQL. You can operate on _val but not on
_val.property1.property2.property25.


>* "_key > ?": Caused by: org.h2.jdbc.JdbcSQLException: Deserialization
> failed, cause: "class org.apache.ignite.binary.BinaryObjectException: Not
> enough data to read the value [position=1, requiredBytes=4,
> remainingBytes=0]"; SQL statement: SELECT "cache".QUERYPERSON._KEY __C0,
> "cache".QUERYPERSON._VAL __C1 FROM "cache".QUERYPERSON WHERE _KEY > ?1
> [90027-175]
>

Looks like a bug to me. Could you open Jira issue with simple reproducible
test?

Sergi


>
>
>
> On Mon, Jan 25, 2016 at 6:38 PM, Sergi Vladykin 
> wrote:
>
> > - Yes, in SQL it is possible to query cache key and value using aliases
> > _key and _val respectively.
> > - Aggregate functions like SUM, AVG, MIN, MAX are supported.
> > - Nested fields are supported and they are flattened, so name collisions
> > are prohibited.
> >
> > Sergi
> >
> > 2016-01-25 15:26 GMT+03:00 Pavel Tupitsyn :
> >
> > > Igniters,
> > >
> > > In relation to .NET LINQ task [1], I'd like to know as much as possible
> > > about Ignite-specific SQL syntax. Our docs [2] do not cover everything.
> > >
> > > * Is it possible to query cache keys? E.g. "key > 10", or "key.field =
> > 1"?
> > > * Is it possible to query scalars, like "sum()"?
> > > * What about nested fields? From examples, I see that nested fields get
> > > flattened, so instead of Address.Zip you can just use Zip. Are there
> any
> > > limitations? What if there is field name collision?
> > >
> > > Where should I look to understand this better?
> > >
> > > Thanks.
> > >
> > > [1] https://issues.apache.org/jira/browse/IGNITE-1630
> > > [2] https://apacheignite.readme.io/docs/sql-queries
> > >
> > > --
> > > --
> > > Pavel Tupitsyn
> > > GridGain Systems, Inc.
> > > www.gridgain.com
> > >
> >
>
>
>
> --
> --
> Pavel Tupitsyn
> GridGain Systems, Inc.
> www.gridgain.com
>


Re: Ignite SQL syntax: key fields, scalars, nested fields

2016-01-25 Thread Pavel Tupitsyn
Thank you Sergi, more questions:

- How do I get the result of an aggregate? Via Fields query? Will it always
be a single value, or a value per node?
- If field names are flattened, what are QueryEntity.aliases for? Javadoc
talks about dot notation, I thought it is for nested fields.
- What is the purpose of SqlQuery.type? We use simple name of the class for
it everywhere. Does it relate to type id mapping somehow?
- I tried to use _key/_val aliases and could not get them to work:
   * "_val.Age > ?": Failed to parse query: SELECT
"cache".QueryPerson._key, "cache".QueryPerson._val FROM "cache".QueryPerson
WHERE _val.Age > ?
   * "_key > ?": Caused by: org.h2.jdbc.JdbcSQLException: Deserialization
failed, cause: "class org.apache.ignite.binary.BinaryObjectException: Not
enough data to read the value [position=1, requiredBytes=4,
remainingBytes=0]"; SQL statement: SELECT "cache".QUERYPERSON._KEY __C0,
"cache".QUERYPERSON._VAL __C1 FROM "cache".QUERYPERSON WHERE _KEY > ?1
[90027-175]



On Mon, Jan 25, 2016 at 6:38 PM, Sergi Vladykin 
wrote:

> - Yes, in SQL it is possible to query cache key and value using aliases
> _key and _val respectively.
> - Aggregate functions like SUM, AVG, MIN, MAX are supported.
> - Nested fields are supported and they are flattened, so name collisions
> are prohibited.
>
> Sergi
>
> 2016-01-25 15:26 GMT+03:00 Pavel Tupitsyn :
>
> > Igniters,
> >
> > In relation to .NET LINQ task [1], I'd like to know as much as possible
> > about Ignite-specific SQL syntax. Our docs [2] do not cover everything.
> >
> > * Is it possible to query cache keys? E.g. "key > 10", or "key.field =
> 1"?
> > * Is it possible to query scalars, like "sum()"?
> > * What about nested fields? From examples, I see that nested fields get
> > flattened, so instead of Address.Zip you can just use Zip. Are there any
> > limitations? What if there is field name collision?
> >
> > Where should I look to understand this better?
> >
> > Thanks.
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-1630
> > [2] https://apacheignite.readme.io/docs/sql-queries
> >
> > --
> > --
> > Pavel Tupitsyn
> > GridGain Systems, Inc.
> > www.gridgain.com
> >
>



-- 
-- 
Pavel Tupitsyn
GridGain Systems, Inc.
www.gridgain.com


Re: MyBatis and Apache Ignite integration

2016-01-25 Thread Denis Magda

HI All,

I've opened an Ignite ticket with tasks description [1]

Is there anyone in Apache Ignite community who is interested in this 
kind of work and will be able to complete it in the nearest couple of weeks?


[1] https://issues.apache.org/jira/browse/IGNITE-2448

Regards,
Denis

On 1/23/2016 11:28 AM, dma...@gridgain.com wrote:

Hi Eduardo,

It's nice to hear from you! Thanks the help and details!

Absolutely agree with you that the interface is straightforward and I 
don't see any difficulties that can arise during its implementation.
I'll open an Apache Ignite JIRA ticket soon describing the integration 
details and hope that someone from Ignite community will pick it up 
the next week starting working on the plugin.


As per the hosting I would host everything on MyBatis GitHub repo as 
it is already done for other plugins and in addition would add a 
documentation to Apache Ignite [1]. This way both MyBatis and Ignite 
community will be aware about the integration and we don't need to 
host the plugin in different repos.


I've copied Ignite dev community to the discussion - 
dev@ignite.apache.org. So please make sure that this dev list is 
copied when you reply ;)


If someone else from either MyBatis or Ignite community has any 
thoughts on this topic please share.


[1] https://apacheignite.readme.io

Regards,
Denis

On Saturday, January 23, 2016 at 12:46:08 AM UTC+3, Eduardo wrote:

Hi Denis,

First of all. Wellcome to the list!

AFAIK all the cache integration plugins have been developed by
ourselves. The interface is quite easy so the task is usualy
pretty straight forward.

I will be very happy to help with the integration! I would suggest
creating a new repo and work on it. Probably it will be better
that that someone from the Ignite project builds the plugin and we
provide information about how the interface works.

Regarding the future hosting, I suppose there will be no problem
in hosting the new project at our home in Github but is also
perfect that you host it as part of the ignite project. No problem
at all with any option!

Looking forward to starting! :)

2016-01-21 10:30 GMT+01:00 >:

Hi MyBatis community!

I'm a committer and PMC of Apache Ignite [1] project and
writing to you on behalf of our community (+ CC-ed) to discuss
an integration between our projects that should be useful for
both sides.

In short, Apache Ignite is a high-performance, integrated and
distributed in-memory platform for computing and transacting
on large-scale data sets in real-time, orders of magnitude
faster than possible with traditional disk-based or flash
technologies.
Inside of our community we see a growing interest in a field
of usage MyBatis along with Apache Ignite. There are use cases
when developers/users wants to use Apache Ignite as MyBatis
second level cache. Since such an interest is growing
constantly we think that it's a right time to make this happen.

As I see MyBatis already supports second level cache for
Redis, Hazelcast and Ehcache.

How do you usually add such components? Were they added by
MyBatis guys or were developed by guys from Redis, Hazelcast,
etc.?

[1] https://ignite.apache.org/

Regards,
Denis

-- 
You received this message because you are subscribed to the

Google Groups "mybatis-user" group.
To unsubscribe from this group and stop receiving emails from
it, send an email to mybatis-user...@googlegroups.com
.
For more options, visit https://groups.google.com/d/optout
.


--
You received this message because you are subscribed to a topic in the 
Google Groups "mybatis-user" group.
To unsubscribe from this topic, visit 
https://groups.google.com/d/topic/mybatis-user/CxSqG1dprm4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 
mybatis-user+unsubscr...@googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.




[jira] [Created] (IGNITE-2448) Ignite based second level cache for MyBatis

2016-01-25 Thread Denis Magda (JIRA)
Denis Magda created IGNITE-2448:
---

 Summary: Ignite based second level cache for MyBatis
 Key: IGNITE-2448
 URL: https://issues.apache.org/jira/browse/IGNITE-2448
 Project: Ignite
  Issue Type: New Feature
Reporter: Denis Magda


MyBatis [1] has a concept of a second level cache.

It makes sense to implement a module that will allow to use Ignite as a second 
level cache for this framework.

In particular the following has to be done:
- introduce ignite-cache module that will be located in MyBatis GIT repository 
[2]
- implement MyBatis {{Cache}} interface [3]
- there should be configs inside of the module for different exemplary cases 
(server node with a single local cache; server node that is a part of some 
cluster and caches mybatis data in replicatred or partitioned cache; client 
nodes that connects to the cluster and works with the cache); 
- add documentation about the integration on Ignite readme.io
- as a reference you may refer to Hazelcast [4] or other implementation

More on caches in MyBatis
http://www.mybatis.org/mybatis-3/sqlmap-xml.html#cache

[1] http://www.mybatis.org/
[2] https://github.com/mybatis/
[3] 
https://github.com/mybatis/mybatis-3/blob/master/src/main/java/org/apache/ibatis/cache/Cache.java
[4] https://github.com/mybatis/hazelcast-cache



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


Re: Ignite SQL syntax: key fields, scalars, nested fields

2016-01-25 Thread Sergi Vladykin
- Yes, in SQL it is possible to query cache key and value using aliases
_key and _val respectively.
- Aggregate functions like SUM, AVG, MIN, MAX are supported.
- Nested fields are supported and they are flattened, so name collisions
are prohibited.

Sergi

2016-01-25 15:26 GMT+03:00 Pavel Tupitsyn :

> Igniters,
>
> In relation to .NET LINQ task [1], I'd like to know as much as possible
> about Ignite-specific SQL syntax. Our docs [2] do not cover everything.
>
> * Is it possible to query cache keys? E.g. "key > 10", or "key.field = 1"?
> * Is it possible to query scalars, like "sum()"?
> * What about nested fields? From examples, I see that nested fields get
> flattened, so instead of Address.Zip you can just use Zip. Are there any
> limitations? What if there is field name collision?
>
> Where should I look to understand this better?
>
> Thanks.
>
> [1] https://issues.apache.org/jira/browse/IGNITE-1630
> [2] https://apacheignite.readme.io/docs/sql-queries
>
> --
> --
> Pavel Tupitsyn
> GridGain Systems, Inc.
> www.gridgain.com
>


Ignite Readme.IO UX issue

2016-01-25 Thread Alexey Kuznetsov
Hi!

Does someone knows it is possible or not to "sync" left pane with
documentation categories and right pane with content of some selected
category?

For example: https://apacheignite.readme.io/docs/igfs

I see some IGFS documentation, but on the left pane I do not see selected
category "IGFS", I need to scroll down. This is very annoying when you are
reading several related topics - you need to scroll every time.

As I know readme.io is a kind of CMS, so who knows how to open an issue for
them?
Do they have any kind of JIRA / mail list / support forum?

-- 
Alexey Kuznetsov
GridGain Systems
www.gridgain.com


[jira] [Created] (IGNITE-2447) ODBC: Consistent naming of Java classes.

2016-01-25 Thread Vladimir Ozerov (JIRA)
Vladimir Ozerov created IGNITE-2447:
---

 Summary: ODBC: Consistent naming of Java classes.
 Key: IGNITE-2447
 URL: https://issues.apache.org/jira/browse/IGNITE-2447
 Project: Ignite
  Issue Type: Sub-task
  Components: odbc
Affects Versions: 1.5.0.final
Reporter: Vladimir Ozerov
Assignee: Igor Sapego
 Fix For: 1.6


We usually name Java classes as follows: [Component][Name]. Also we do not use 
"Grid" prefix anymore. All existing "Grid*" classes are legacy from GridGain 
days.

Please rename the classes as follows:
{code}
GridOdbcParser -> OdbcParser
GridTcpOdbcNioListener -> OdbcTcpNioListener
etc.
{code}

Also we usually do not split classes into multiple packages unless it is really 
needed. You can safely put all classes into a single package 
"org.apache.ignite.internal.processors.odbc".



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


[jira] [Created] (IGNITE-2446) ODBC: OdbcConfiguration must have "host" property.

2016-01-25 Thread Vladimir Ozerov (JIRA)
Vladimir Ozerov created IGNITE-2446:
---

 Summary: ODBC: OdbcConfiguration must have "host" property.
 Key: IGNITE-2446
 URL: https://issues.apache.org/jira/browse/IGNITE-2446
 Project: Ignite
  Issue Type: Sub-task
  Components: odbc
Affects Versions: 1.5.0.final
Reporter: Vladimir Ozerov
Assignee: Igor Sapego
 Fix For: 1.6


This will allow user to bind to arbitrary network interface if needed.
See other components (e.g. ConnectorConfiguration) for reference.



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


[jira] [Created] (IGNITE-2445) IgntieConfiguration.odbcConfiguration must have sensible JavaDocs.

2016-01-25 Thread Vladimir Ozerov (JIRA)
Vladimir Ozerov created IGNITE-2445:
---

 Summary: IgntieConfiguration.odbcConfiguration must have sensible 
JavaDocs.
 Key: IGNITE-2445
 URL: https://issues.apache.org/jira/browse/IGNITE-2445
 Project: Ignite
  Issue Type: Sub-task
  Components: odbc
Affects Versions: 1.5.0.final
Reporter: Vladimir Ozerov
Assignee: Igor Sapego
 Fix For: 1.6






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


Re: Binary ID mapper that uses a simple name of classes.

2016-01-25 Thread Alexey Goncharuk
Dmitriy,

I did a code review of the PR with Artem and I think I understood the need
for two mappers. First, name mapper is used to map platform (Java, .NET,
C++) class name to a common platform-independent type name. This name is
used in SQL table name and it is also passed to ID mapper. ID mapper is
used to resolve possible conflicts of default type IDs.

By default user will not need to configure anything if he uses solely Java
or .NET. Mappers need to be configured if there is a tricky name conversion
when platform interoperability is needed.
​
Hope this makes sense.

--AG


[jira] [Created] (IGNITE-2444) ODBC: odbc.sln references VS2014.

2016-01-25 Thread Vladimir Ozerov (JIRA)
Vladimir Ozerov created IGNITE-2444:
---

 Summary: ODBC: odbc.sln references VS2014.
 Key: IGNITE-2444
 URL: https://issues.apache.org/jira/browse/IGNITE-2444
 Project: Ignite
  Issue Type: Sub-task
  Components: odbc
Affects Versions: 1.5.0.final
Reporter: Vladimir Ozerov
Assignee: Igor Sapego
 Fix For: 1.6


*NB*: This ticket doesn't make sense if we decide to get rid of odbc.sln (see 
IGNITE-2442).

ignite.sln:
{code}
Microsoft Visual Studio Solution File, Format Version 11.00
# Visual Studio 2010
{code}

odbc.sln:
{code}
Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio 14
VisualStudioVersion = 14.0.23107.0
MinimumVisualStudioVersion = 10.0.40219.1
{code}

I think we'd better avoid any mention of VS other than VS2010. 




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


Re: ignite cache process entry should inject source?

2016-01-25 Thread 姜 为
Hi Denis,

I create example project https://github.com/wmz7year/ignite-example 
.

Please see README file to run example.

Wei Jiang


> 在 2016年1月23日,上午2:40,Denis Magda  写道:
> 
> Hi Wei Jiang,
> 
> I would better review your current approach to have better understanding on 
> what you're trying to implement.
> 
> Please share the code. If it's the same as being discussed in "about AOP 
> development" thread that let me know, I'll take a look there.
> 
> --
> Denis
> 
> On 1/22/2016 10:28 AM, 姜 为 wrote:
>> Hi Denis,
>> 
>>  How about provide an option for this?
>> 
>>  Ignite cache user can chose enable or disable inject resources.
>> 
>> Wei Jiang
>> 
>>> 在 2016年1月22日,下午3:22,Denis Magda  写道:
>>> 
>>> Hi Wei Jiang,
>>> 
>>> You can inject @SpringResource and @SpringApplicationContextResource into 
>>> Ignite Service or Ignite Compute. This feature is not supported for 
>>> individual cache entries, at least because of performance reasons.
>>> @Autowired is unsupported for both Ignite services and computes.
>>> 
>>> So if you need to process the entries inside of Ignite Compute or Ignite 
>>> Service then just inject a resource there using one of the annotations 
>>> above.
>>> 
>>> The main point here is that all the nodes have to be started as a part of 
>>> spring app context or have to have a reference to it.
>>> Please refer to org.apache.ignite.IgniteSpring for more info.
>>> 
>>> Regards,
>>> Denis
>>> 
>>> On 1/22/2016 10:07 AM, 姜 为 wrote:
 Hi Denis,

I try to use Ignite cache to store the service object.
The object use Externalizable interface and has a @Autowired field.

When different node use this object, the @Autowired field will be 
 null,even @SpringResources on the field.
 
The field like JPA interface , it can’t be serialization.
 
 Wei Jiang
 
 
> 在 2016年1月22日,下午2:58,Denis Magda  写道:
> 
> Hi,
> 
> Spring resource injection is considered to be used only for Ignite 
> Compute Jobs.
> 
> It's quite expensive operation to inject a resource for a CacheEntry 
> cause this logic will be called for every entry stored in a cache.
> 
> Why do you need to inject the resource into a CacheEntry? What do you try 
> to achieve?
> 
> Regards,
> Denis
> 
> On 1/22/2016 6:26 AM, 姜 为 wrote:
>> Hi Igniters,
>>  
>>  I’m using Ignite cache store objects.  The object use Externalizable 
>> interface
>> to serialization  and deserialization.
>>  When object has field use @SpringSource will not inject.
>> 
>>  Should add resource inject to Ignite cache?
>> 
>>  example :
>> 
>>  class Entey implements Externalizable {
>>   @SpringSource(“springSource")
>>private Service service;
>>   public void read… and write...
>>}
> 



[jira] [Created] (IGNITE-2443) ODBC: Ensure that versions of new CPP projects are updated correctly.

2016-01-25 Thread Vladimir Ozerov (JIRA)
Vladimir Ozerov created IGNITE-2443:
---

 Summary: ODBC: Ensure that versions of new CPP projects are 
updated correctly.
 Key: IGNITE-2443
 URL: https://issues.apache.org/jira/browse/IGNITE-2443
 Project: Ignite
  Issue Type: Sub-task
  Components: odbc
Affects Versions: 1.5.0.final
Reporter: Vladimir Ozerov
 Fix For: 1.6


We have automated TC task for version updates. It is necessary need to ensure 
that versions of new ODBC components (both VS and autotools) are updated as 
well.




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


[jira] [Created] (IGNITE-2442) ODBC: Is there any reason to have separate VS solution for ODBC?

2016-01-25 Thread Vladimir Ozerov (JIRA)
Vladimir Ozerov created IGNITE-2442:
---

 Summary: ODBC: Is there any reason to have separate VS solution 
for ODBC?
 Key: IGNITE-2442
 URL: https://issues.apache.org/jira/browse/IGNITE-2442
 Project: Ignite
  Issue Type: Sub-task
  Components: odbc
Affects Versions: 1.5.0.final
Reporter: Vladimir Ozerov
Assignee: Igor Sapego
 Fix For: 1.6


Usually we are trying to maintain flat projects structure. E.g. see Java root - 
single project hosts all modules.
I propose to do the following:
1) Rename "odbc-driver" to "odbc" and move it to the main CPP solution.
2) Move "odbc-test" to the main CPP solution.

Igor, do you see any issues with this approach?



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


[jira] [Created] (IGNITE-2441) ODBC: binary.vcxproj has invalid build tools version.

2016-01-25 Thread Vladimir Ozerov (JIRA)
Vladimir Ozerov created IGNITE-2441:
---

 Summary: ODBC: binary.vcxproj has invalid build tools version.
 Key: IGNITE-2441
 URL: https://issues.apache.org/jira/browse/IGNITE-2441
 Project: Ignite
  Issue Type: Sub-task
  Components: odbc
Affects Versions: 1.5.0.final
Reporter: Vladimir Ozerov
Assignee: Igor Sapego
 Fix For: 1.6


"http://schemas.microsoft.com/developer/msbuild/2003";>"

VS2010 build tools should be used instead.



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


[jira] [Created] (IGNITE-2440) [Test] [Rare] IgniteCacheAtomicQuerySelfTest.testExpiration

2016-01-25 Thread Vladimir Ershov (JIRA)
Vladimir Ershov created IGNITE-2440:
---

 Summary: [Test] [Rare] 
IgniteCacheAtomicQuerySelfTest.testExpiration
 Key: IGNITE-2440
 URL: https://issues.apache.org/jira/browse/IGNITE-2440
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 1.5.0.final
Reporter: Vladimir Ershov
Priority: Minor


Test failes sometimes: IgniteCacheAtomicQuerySelfTest.testExpiration
{noformat}
junit.framework.AssertionFailedError: Expected:  but was: Entry [key=7, 
val=1]
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.Assert.assertTrue(Assert.java:22)
at junit.framework.Assert.assertNull(Assert.java:277)
at junit.framework.Assert.assertNull(Assert.java:268)
at junit.framework.TestCase.assertNull(TestCase.java:438)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheAbstractQuerySelfTest.testExpiration(IgniteCacheAbstractQuerySelfTest.java:395)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at junit.framework.TestCase.runTest(TestCase.java:176)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1699)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:116)
at 
org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1637)
at java.lang.Thread.run(Thread.java:745)
--- Stdout: ---
[09:20:33,658][INFO ][main][root] >>> Starting test: testExpiration <<<
[09:20:34,793][INFO ][main][root] >>> Stopping test: testExpiration in 1135 ms 
<<<
--- Stderr: ---
[09:20:34,792][ERROR][main][root] Test failed.
junit.framework.AssertionFailedError: Expected:  but was: Entry [key=7, 
val=1]
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.Assert.assertTrue(Assert.java:22)
at junit.framework.Assert.assertNull(Assert.java:277)
at junit.framework.Assert.assertNull(Assert.java:268)
at junit.framework.TestCase.assertNull(TestCase.java:438)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheAbstractQuerySelfTest.testExpiration(IgniteCacheAbstractQuerySelfTest.java:395)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at junit.framework.TestCase.runTest(TestCase.java:176)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1699)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:116)
at 
org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1637)
at java.lang.Thread.run(Thread.java:745)
{noformat}



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


Ignite SQL syntax: key fields, scalars, nested fields

2016-01-25 Thread Pavel Tupitsyn
Igniters,

In relation to .NET LINQ task [1], I'd like to know as much as possible
about Ignite-specific SQL syntax. Our docs [2] do not cover everything.

* Is it possible to query cache keys? E.g. "key > 10", or "key.field = 1"?
* Is it possible to query scalars, like "sum()"?
* What about nested fields? From examples, I see that nested fields get
flattened, so instead of Address.Zip you can just use Zip. Are there any
limitations? What if there is field name collision?

Where should I look to understand this better?

Thanks.

[1] https://issues.apache.org/jira/browse/IGNITE-1630
[2] https://apacheignite.readme.io/docs/sql-queries

-- 
-- 
Pavel Tupitsyn
GridGain Systems, Inc.
www.gridgain.com


Re: Marking fixed JIRAs against releases

2016-01-25 Thread Yakov Zhdanov
I did.

--Yakov

2016-01-25 8:22 GMT+03:00 Konstantin Boudnik :

> perhaps, someone with JIRA admin permissions need to rename the version
> number
> then to avoid the confusion?
>
> Cos
>
> On Fri, Jan 22, 2016 at 06:57PM, Dmitriy Setrakyan wrote:
> > I would say 1.5.0.final (the beta did not include all the fixes).
> >
> > On Fri, Jan 22, 2016 at 5:26 PM, Konstantin Boudnik 
> wrote:
> >
> > > Another issue: JIRA has release 1.5, however to my knowledge the
> project
> > > had
> > > at least
> > > 1.5.0-b1
> > > 1.5.0.final
> > >
> > > Which one JIRA's version is related to?
> > >   Cos
> > >
> > > On Thu, Jan 21, 2016 at 05:33AM, Konstantin Boudnik wrote:
> > > > There might be a way to enforce it on the JIRA side, I just have no
> > > idea, to
> > > > be honest. The best way is to file INFRA and ask them to help
> > > >
> > > > Cos
> > > >
> > > > On Tue, Jan 19, 2016 at 04:12PM, Yakov Zhdanov wrote:
> > > > > Cos, very good catch.
> > > > >
> > > > > 1. Agree with Dmitry that it would be better to enforce version is
> set
> > > on
> > > > > close/resolution.
> > > > > 2. As far as already closed tickets let's have everyone review
> tickets
> > > > > closed by himself and put proper fixVersion.
> > > > >
> > > > > --Yakov
> > > > >
> > > > > 2016-01-19 9:53 GMT+03:00 Dmitriy Setrakyan  >:
> > > > >
> > > > > > Cos, to my knowledge, the release notes are generated by
> searching
> > > for a
> > > > > > fix version, so the tickets you are pointing out will likely be
> > > missed.
> > > > > >
> > > > > > Generally speaking all fixed tickets should have a fix version.
> > > Let’s make
> > > > > > sure that we follow this rule going forward. (Any way to enforce
> it?)
> > > > > >
> > > > > > D.
> > > > > >
> > > > > > On Mon, Jan 18, 2016 at 3:50 PM, Konstantin Boudnik <
> c...@apache.org>
> > > > > > wrote:
> > > > > >
> > > > > > > Guys,
> > > > > > >
> > > > > > > as a fall-out from another conversation I've ran the following
> > > search on
> > > > > > > JIRA
> > > > > > >
> > > > > > > project = ignite and status in (Fixed, Closed) and
> fixVersion
> > > is null
> > > > > > >
> > > > > > > and we have 150 (yes, some of them are dups and won't fixes)
> > > closed/fixed
> > > > > > > tickets without explicit fixVersion on them. How do we keep
> track
> > > of what
> > > > > > > is a
> > > > > > > particular release and what's not? How the Release Notes are
> > > generated?
> > > > > > >
> > > > > > > Regards,
> > > > > > >   Cos
> > > > > > >
> > > > > >
> > >
> > >
> > >
>


[GitHub] ignite pull request: IGNITE-2439: Remove NULL and from i...

2016-01-25 Thread isapego
GitHub user isapego opened a pull request:

https://github.com/apache/ignite/pull/421

IGNITE-2439: Remove NULL and  from interop_stream_position_guard.h

…guard.h.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/isapego/ignite ignite-2439

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/421.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #421


commit 6a8b24bea648d3722ea8d82c94b865fbfa519835
Author: isapego 
Date:   2016-01-25T12:09:05Z

IGNITE-2439: Removed NULL and  from 
interop_stream_position_guard.h.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[jira] [Created] (IGNITE-2439) Remove NULL and from interop_stream_position_guard.h

2016-01-25 Thread Vladimir Ozerov (JIRA)
Vladimir Ozerov created IGNITE-2439:
---

 Summary: Remove NULL and  from 
interop_stream_position_guard.h
 Key: IGNITE-2439
 URL: https://issues.apache.org/jira/browse/IGNITE-2439
 Project: Ignite
  Issue Type: Sub-task
  Components: odbc
Affects Versions: 1.5
Reporter: Vladimir Ozerov
Assignee: Igor Sapego
 Fix For: 1.6


Looks like we do not need it. "0" can be used instead.



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


[jira] [Created] (IGNITE-2438) IGFS: in dual modes file modification time should be propagated from the underlying Fs.

2016-01-25 Thread Ivan Veselovsky (JIRA)
Ivan Veselovsky created IGNITE-2438:
---

 Summary: IGFS: in dual modes file modification time should be 
propagated from the underlying Fs.
 Key: IGNITE-2438
 URL: https://issues.apache.org/jira/browse/IGNITE-2438
 Project: Ignite
  Issue Type: Bug
  Components: IGFS
Affects Versions: 1.5
Reporter: Ivan Veselovsky
Assignee: Ivan Veselovsky
 Fix For: 1.6


Currently IGFS in dual mode reports file modification time as the time when 
that file was created on IGFS (propagated from underlying file system). 
But should report exact copy of the underlying file system file modification 
time.



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


[GitHub] ignite pull request: IGNITE-2343: workable fix for the customer is...

2016-01-25 Thread asfgit
Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/399


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


Re: LINQ support in Ignite.NET via re-linq library

2016-01-25 Thread Pavel Tupitsyn
Val, ToQueryable comes from standard IQueryable/IEnumerable interfaces.
IEnumerable is a very basic interface that all the collections implement
(lists, arrays, etc).
IQueryable implements IEnumerable, but adds Provider which evaluates the
query.

Our ICache is already IEnumerable (it delegates to IgniteCache.iterator()
in Java).
So you can already say 'cache.Where(e => e.Key > 10)' and so on, but the
filtering will occur locally, as opposed to 'ToQueryable().Where(...)'.

I think this is a good design. Any cache can be iterated, but queries have
to be configured, and ToQueryable clearly states that user wants to use SQL
queries.

Thoughts?

On Sat, Jan 23, 2016 at 9:58 AM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Looks nice, but what is ToQueryable() method for? Is the cache initially
> not queryable? :)
>
> -Val
>
> On Fri, Jan 22, 2016 at 9:49 AM, Sergi Vladykin 
> wrote:
>
> > Looks cool to me.
> >
> > Sergi
> >
> > 2016-01-22 18:04 GMT+03:00 Pavel Tupitsyn :
> >
> > > Igniters,
> > >
> > > I'm working on LINQ support in Ignite.NET ([1]).
> > >
> > > For the uninitiated, LINQ will allow cache SQL queries in a
> > strongly-typed
> > > way, which is awesome:
> > >   cache.ToQueryable().Where(person => person.Age > 20)
> > > instead of
> > >   cache.Query(new SqlQuery(typeof(Person), "age > ?", 20))
> > >
> > > To greatly simplify the task of transforming expression tree to Ignite
> > SQL,
> > > I'm going to use re-linq [2].
> > > * It is an industry standard LINQ library, used in Entity Framework and
> > > NHibernate for the same purpose
> > > * License is Apache 2.0, same as ours
> > >
> > > Any thoughts or objections?
> > >
> > >
> > > [1] https://issues.apache.org/jira/browse/IGNITE-1630
> > > [2] https://relinq.codeplex.com/
> > >
> > > --
> > > --
> > > Pavel Tupitsyn
> > > GridGain Systems, Inc.
> > > www.gridgain.com
> > >
> >
>



-- 
-- 
Pavel Tupitsyn
GridGain Systems, Inc.
www.gridgain.com