Re: Move documentation from readme.io to GitHub pages

[Konstantin Boudnik]

I hate to be that guy, but mentors warned this very project no to do
this in the first place. At least once [1] on the dev@, and a few
times off-line

[1] https://is.gd/ZRPOrH

Cos

--
  Take care,
Konstantin (Cos) Boudnik
2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622

Disclaimer: Opinions expressed in this email are those of the author,
and do not necessarily represent the views of any company the author
might be affiliated with at the moment of writing.


On Tue, Apr 11, 2017 at 9:57 PM, Dmitriy Setrakyan
 wrote:
> Pavel,
>
> We all agree that the documentation should be in our GIT repo in either
> Markdown or AsciiDoc format. However, it is a very big undertaking to
> migrate it from readme and properly structure it. If anyone in the
> community would volunteer, would be great.
>
> D.
>
> On Tue, Apr 11, 2017 at 9:36 PM, Pavel Tupitsyn 
> wrote:
>
>> > Git approach is no way to go for us because all the documentation has to
>> be hosted on ASF side
>>
>> Well, our Git repository [1] is hosted by ASF, isn't it?
>> GitHub pages just generates HTML from MarkDown via Jekyll [2] static site
>> generator.
>>
>> I understand the concern about GitHub pages, though.
>> And Igor is right about different versions, seems like it may be not so
>> easy with GH pages.
>>
>>
>> So I propose to use Jekyll, but do not use GitHub pages:
>> * Keep documentation in our Git repository in MarkDown format
>> * Generate HTML when release comes out and upload it to ignite.apache.org
>> (same as we do for API docs [3])
>>
>> Seems to be easy enough. The hardest part is to come up with a good
>> template.
>>
>> Thoughts?
>>
>>
>> [1] https://git-wip-us.apache.org/repos/asf?p=ignite.git
>> [2] https://jekyllrb.com/
>> [3] https://ignite.apache.org/releases/1.8.0/javadoc/
>>
>> On Tue, Apr 11, 2017 at 7:09 PM, Denis Magda  wrote:
>>
>> > Pavel,
>> >
>> > I totally agree that it’s becoming more and more inconvenient to run the
>> > documentation on readme.io . At the same time the Git
>> > approach is no way to go for us because all the documentation has to be
>> > hosted on ASF side. Presently we violate this policy and I look forward
>> we
>> > fix it pretty soon.
>> >
>> > So, in general, all the documentation content has to become a part of
>> > Apache Ignite site and available from there. Here are some of the
>> examples
>> > of another ASF projects:
>> > http://spark.apache.org/docs/2.1.0/ > >
>> > https://zeppelin.apache.org/contribution/documentation.html <
>> > https://zeppelin.apache.org/contribution/documentation.html>
>> > https://hadoop.apache.org/docs/r2.7.2/ > > docs/r2.7.2/>
>> >
>> > Are you aware of any ready-to-be-used documentation libs that can be
>> > easily reused by us?
>> >
>> > —
>> > Denis
>> >
>> > > On Apr 11, 2017, at 2:02 AM, Pavel Tupitsyn 
>> > wrote:
>> > >
>> > > Igniters,
>> > >
>> > > Currently we host documentation on
>> > > apacheignite.readme.io (and also apacheignite-net.readme.io,
>> > > apacheignite-cpp.readme.io, apacheignite-mix.readme.io, etc).
>> > >
>> > > readme.io has a lot of problems mostly due to lack of proper version
>> > > control:
>> > > * Each "version" is just a copy. When fixing something, you have to
>> > update
>> > > all versions.
>> > > * No good way to review changes.
>> > > * "Propose edit" functionality is a joke. You can only accept or reject
>> > an
>> > > edit, no way to communicate with contributor, etc
>> > >
>> > > GitHub Pages solves all these problems:
>> > > https://github.com/blog/2233-publish-your-project-
>> > documentation-with-github-pages
>> > >
>> > > Basically, we'll have a separate folder in our Git repository where
>> > > documentation is stored in markdown format.
>> > > This way the process for updating docs is exactly the same as any other
>> > > code change.
>> > > Pull request with new feature can contain the docs for this feature,
>> and
>> > so
>> > > on.
>> > >
>> > > Thoughts?
>> >
>> >
>>

Webinar: Apache Ignite as a backbone for microservices-based architectures

[Denis Magda]

Dear community,

Welcome you to join the next Apache Ignite related webinar where you can learn 
more about Service Grid component and how to apply it for microservices-based 
solutions.

Description and registration: http://bit.ly/2nEmyv1  
Tweet: https://twitter.com/ApacheIgnite/status/852165280700796928

*Prachi*, would you add the event to the news feed?
https://ignite.apache.org/news.html 

—
Denis

Re: TouchedExpiryPolicy works incorrect in some cases IGNITE-4401

[Denis Magda]

Bluntly speaking I have no idea where to look and what to expect. This is 
output of the test execution of my machine:

SQL res: [[1], [d]]
2
Op consume: 303
Value: org.ignite.test.EDU@22db8f4
SQL res: []
0
Op consume: 9
Value: org.ignite.test.EDU@29caf222
SQL res: []
0
Op consume: 15
Value: org.ignite.test.EDU@7cd1ac19
SQL res: []
0
Op consume: 5

Please be more specific, there are too many files in the code. 

—
Denis

> On Apr 12, 2017, at 4:50 AM, ALEKSEY KUZNETSOV  
> wrote:
> 
> So what do u think about the issue ?
> 
> ср, 12 апр. 2017 г. в 10:42, ALEKSEY KUZNETSOV :
> 
>> I have already attached simlified version. Shall i simplify it more ?
>> 
>> вт, 11 апр. 2017 г. в 19:28, Denis Magda :
>> 
>> Can you attach the simplified version? Just want to avoid any side effects.
>> 
>> —
>> Denis
>> 
>>> On Apr 11, 2017, at 9:14 AM, ALEKSEY KUZNETSOV 
>> wrote:
>>> 
>>> I took it from https://issues.apache.org/jira/browse/IGNITE-4401 <
>> https://issues.apache.org/jira/browse/IGNITE-4401> and simplified . See
>> in attached
>>> 
>>> 
>>> вт, 11 апр. 2017 г. в 19:03, Denis Magda  dma...@apache.org>>:
>>> Hello,
>>> 
>>> Do you have sample code?
>>> 
>>> —
>>> Denis
 On Apr 11, 2017, at 2:45 AM, ALEKSEY KUZNETSOV <
>> alkuznetsov...@gmail.com > wrote:
 
 Hi, igniters!
 While doing https://issues.apache.org/jira/browse/IGNITE-4401 <
>> https://issues.apache.org/jira/browse/IGNITE-4401> ticket i came
 across the fact that cache querying returns null , while cache still
>> has
 got entry.
 Cache query : SELECT nameProp FROM EDUProp WHERE EDUId = 1
 Cache get operation : ignite().cache("eduPropCache").get(new
>> AffinityKey("1",
 "1")) non-null
 I cannot even imagine what could be wrong with it.
 
 
 
 --
 
 *Best Regards,*
 
 *Kuznetsov Aleksey*
>>> 
>>> --
>>> Best Regards,
>>> 
>>> Kuznetsov Aleksey
>>> 
>> 
>> --
>> 
>> *Best Regards,*
>> 
>> *Kuznetsov Aleksey*
>> 
> -- 
> 
> *Best Regards,*
> 
> *Kuznetsov Aleksey*

Re: Sorting fields of Binarilyzable objects on write

[Dmitriy Setrakyan]

Vladimir,

Would this be valid?

*void writeBinary(BinaryWriter w) {*

*if (c)*
*w.writeInt("A", a)*
*else*
*w.writeInt("B", b)*

*w.writeBoolean("C", c);*
*}*

D.

On Wed, Apr 12, 2017 at 1:07 AM, Vladimir Ozerov 
wrote:

> Consider the following code:
>
> void writeBinary(BinaryWriter w) {
> w.writeBoolean("C", c);
>
> if (c)
> w.writeInt("A", a)
> else
> w.writeInt("B", b)
> }
>
> How are we going to force user to follow the contract in this case?
>
> On Wed, Apr 12, 2017 at 9:16 AM, Dmitriy Setrakyan 
> wrote:
>
> > I think it is OK for users to do their own sorting, but we should
> > definitely validate the correct order and throw an exception if it is
> not.
> >
> > D.
> >
> > On Tue, Apr 11, 2017 at 11:02 PM, Pavel Tupitsyn 
> > wrote:
> >
> > > QueryEntity order is not only harder for the users, it will be
> nightmare
> > to
> > > implement.
> > > What if there is no QueryEntity defined? What if the same class is used
> > in
> > > multiple QueryEntity?
> > > I don't think serialization code has to be tied to QueryEntity in any
> > way,
> > > this violates separation of concerns.
> > >
> > > So I guess we can agree on sorting fields alphabetically.
> > >
> > > Let's get to the initial question:
> > > * Should we do the sorting for the user (performance hit)?
> > > * Should we at least validate user-defined order?
> > >
> > > On Wed, Apr 12, 2017 at 2:12 AM, Dmitriy Setrakyan <
> > dsetrak...@apache.org>
> > > wrote:
> > >
> > > > On Tue, Apr 11, 2017 at 1:28 PM, Sergi Vladykin <
> > > sergi.vlady...@gmail.com>
> > > > wrote:
> > > >
> > > > > I'm just trying to understand the current state of things and
> risks.
> > > May
> > > > be
> > > > > we need to do some adjustments here before 2.0 to be on the safe
> > side.
> > > > >
> > > > > Actually looks like this not really important, we just have to
> > clearly
> > > > > document that DML builds keys this way and require from user to do
> > the
> > > > same
> > > > > to be able to use cache API.
> > > > >
> > > >
> > > >
> > > > I think it is important from the usability stand point. A user can
> > always
> > > > sort fields alphabetically in his or her mind. However, trying to
> > > remember
> > > > the field order from some QueryEntity is a lot harder.
> > > >
> > >
> >
>

Re: CachePojoStore data loading with binary marshaller

[Dmitriy Setrakyan]

On Wed, Apr 12, 2017 at 12:24 AM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Hi Dmitry,
>
> I can't advise a lot on implementation details, but generally I don't think
> that CacheJdbcPojoStore should ever work with POJO classes in case binary
> marshaller is enabled. It should always work directly with binary objects
> even if POJOs are on server classpath, and switch to POJOs only when other
> marshaller is used.
>
> Makes sense?
>

Valentin, this makes sense from the performance stand point. However, why
should it be illegal to deserialize a binary object into class, if the
class it on the classpath?

Re: SQL on PARTITIONED vs REPLICATED cache

[Dmitriy Setrakyan]

Got it, Denis. I think you are right.

On Wed, Apr 12, 2017 at 2:20 PM, Denis Magda  wrote:

> Dmitriy,
>
> No, I think that Sergi supposed a type of cache which reference is used
> for a query execution. In my example
>
> >> 2. Error-prone scenario - *replicatedCache*.query(“SELECT * FROM
> >> partitionedCache … JOIN replicatedCache …”);
>
> *replicatedCache* reference is used for the query execution and, as I
> understand, this causes the issue.
>
> Sergi, please clarify.
>
> —
> Denis
>
> > On Apr 12, 2017, at 1:51 PM, Dmitriy Setrakyan 
> wrote:
> >
> > Denis, I think that you meant selecting from replicated cache first as an
> > invalid scenario, but provided the wrong example. Here is the correct
> > example for the invalid query:
> >
> > SELECT * FROM replicatedCache … JOIN partitionedCache …”
> >
> > I do agree, we should make the change, as long as we keep the flag to
> > enable the old behavior.
> >
> > D.
> >
> > On Wed, Apr 12, 2017 at 12:50 PM, Denis Magda  wrote:
> >
> >> Sergi,
> >>
> >> As far as I understand you’re considering an example below:
> >>
> >> IgniteCache partitioneCache = ...;
> >> IgniteCache replicatedCache = …;
> >>
> >> 1. Valid scenario - *partitionedCache*.query(“SELECT * FROM
> >> partitionedCache … JOIN replicatedCache …”);
> >> 2. Error-prone scenario - *replicatedCache*.query(“SELECT * FROM
> >> partitionedCache … JOIN replicatedCache …”);
> >>
> >> Do you mean 2. as the issue? If it’s so then can’t we just detect on our
> >> own that all the caches are replicated and execute a query more optimal?
> >> This should omit necessity to add isReplicatedOnly()?
> >>
> >> —
> >> Denis
> >>
> >>> On Apr 12, 2017, at 7:07 AM, Andrey Mashenkov <
> >> andrey.mashen...@gmail.com> wrote:
> >>>
> >>> Yes, it's reasonable.
> >>>
> >>> On Wed, Apr 12, 2017 at 3:23 PM, Sergi Vladykin <
> >> sergi.vlady...@gmail.com>
> >>> wrote:
> >>>
>  Good point, but I'm not sure. The difference is that on client node
> you
>  should not be able to enable isLocal, while isReplicatedOnly is
> >> perfectly
>  valid. What do you think?
> 
>  Sergi
> 
>  2017-04-12 15:18 GMT+03:00 Andrey Mashenkov <
> andrey.mashen...@gmail.com
> >>> :
> 
> > Sergi,
> >
> > Got it.
> >
> > Does query execution way and results will be same for
> isReplicatedOnly
>  flag
> > and for isLocal flag turned on?
> > If my understanding is correct, we will get same results and there is
> >> no
> > need to introduce a new flag.
> >
> >
> >
> > On Wed, Apr 12, 2017 at 2:54 PM, Sergi Vladykin <
>  sergi.vlady...@gmail.com>
> > wrote:
> >
> >> Ok, let it be an exception. I'm just saying that the thing does not
>  work
> >> now.
> >>
> >> Sergi
> >>
> >> 2017-04-12 14:50 GMT+03:00 Andrey Mashenkov <
>  andrey.mashen...@gmail.com
> >> :
> >>
> >>> Sergi,
> >>>
> >>> I wounder how it is possible?
> >>>
> >>> Looks like it is impossible to run query on replicated cache, but
> > select
> >>> data from a
> >>> partitioned table. It will result with IlleagalStateException on
>  stable
> >>> topology or
> >>> IgniteCacheException on unstable topology.
> >>> See ReduceQueryExecutor.stableDataNodes() and
> >>> replicatedUnstableDataNodes()
> >>> methods.
> >>>
> >>> BTW, IlleagalStateException with no message is confusing.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On Wed, Apr 12, 2017 at 2:36 PM, Sergi Vladykin <
> >> sergi.vlady...@gmail.com>
> >>> wrote:
> >>>
>  Andrey,
> 
>  Because if you run query on replicated cache, but select data from
>  a
>  partitioned table, you will get only a part of the result.
> 
>  Igor,
> 
>  You are mostly right, but
> 
>  1. Performance characteristics may change.
>  2. Ignite SQL processing pipeline may not support all the stuff in
>  H2
> >> SQL
>  and fail in some case where it worked previously.
> 
>  Because of this the change may affect existing applications and I
> > want
> >> to
>  have it in 2.0 to make it legal.
> 
>  Sergi
> 
>  2017-04-12 14:10 GMT+03:00 Igor Sapego :
> 
> > Also, is it really a breaking change if the results are wrong?
> > To me it looks more like a bugfix, i.e. you can't break something
> > that does not work properly.
> >
> > Best Regards,
> > Igor
> >
> > On Wed, Apr 12, 2017 at 2:04 PM, Andrey Mashenkov <
> > andrey.mashen...@gmail.com> wrote:
> >
> >> Sergi,
> >>
> >> How can query to replicated cache leads to to wrong results?
> >> Is it due to we can read backup entries?
> 

Re: SQL on PARTITIONED vs REPLICATED cache

[Denis Magda]

Dmitriy,

No, I think that Sergi supposed a type of cache which reference is used for a 
query execution. In my example

>> 2. Error-prone scenario - *replicatedCache*.query(“SELECT * FROM
>> partitionedCache … JOIN replicatedCache …”);

*replicatedCache* reference is used for the query execution and, as I 
understand, this causes the issue.

Sergi, please clarify.

—
Denis

> On Apr 12, 2017, at 1:51 PM, Dmitriy Setrakyan  wrote:
> 
> Denis, I think that you meant selecting from replicated cache first as an
> invalid scenario, but provided the wrong example. Here is the correct
> example for the invalid query:
> 
> SELECT * FROM replicatedCache … JOIN partitionedCache …”
> 
> I do agree, we should make the change, as long as we keep the flag to
> enable the old behavior.
> 
> D.
> 
> On Wed, Apr 12, 2017 at 12:50 PM, Denis Magda  wrote:
> 
>> Sergi,
>> 
>> As far as I understand you’re considering an example below:
>> 
>> IgniteCache partitioneCache = ...;
>> IgniteCache replicatedCache = …;
>> 
>> 1. Valid scenario - *partitionedCache*.query(“SELECT * FROM
>> partitionedCache … JOIN replicatedCache …”);
>> 2. Error-prone scenario - *replicatedCache*.query(“SELECT * FROM
>> partitionedCache … JOIN replicatedCache …”);
>> 
>> Do you mean 2. as the issue? If it’s so then can’t we just detect on our
>> own that all the caches are replicated and execute a query more optimal?
>> This should omit necessity to add isReplicatedOnly()?
>> 
>> —
>> Denis
>> 
>>> On Apr 12, 2017, at 7:07 AM, Andrey Mashenkov <
>> andrey.mashen...@gmail.com> wrote:
>>> 
>>> Yes, it's reasonable.
>>> 
>>> On Wed, Apr 12, 2017 at 3:23 PM, Sergi Vladykin <
>> sergi.vlady...@gmail.com>
>>> wrote:
>>> 
 Good point, but I'm not sure. The difference is that on client node you
 should not be able to enable isLocal, while isReplicatedOnly is
>> perfectly
 valid. What do you think?
 
 Sergi
 
 2017-04-12 15:18 GMT+03:00 Andrey Mashenkov >> :
 
> Sergi,
> 
> Got it.
> 
> Does query execution way and results will be same for isReplicatedOnly
 flag
> and for isLocal flag turned on?
> If my understanding is correct, we will get same results and there is
>> no
> need to introduce a new flag.
> 
> 
> 
> On Wed, Apr 12, 2017 at 2:54 PM, Sergi Vladykin <
 sergi.vlady...@gmail.com>
> wrote:
> 
>> Ok, let it be an exception. I'm just saying that the thing does not
 work
>> now.
>> 
>> Sergi
>> 
>> 2017-04-12 14:50 GMT+03:00 Andrey Mashenkov <
 andrey.mashen...@gmail.com
>> :
>> 
>>> Sergi,
>>> 
>>> I wounder how it is possible?
>>> 
>>> Looks like it is impossible to run query on replicated cache, but
> select
>>> data from a
>>> partitioned table. It will result with IlleagalStateException on
 stable
>>> topology or
>>> IgniteCacheException on unstable topology.
>>> See ReduceQueryExecutor.stableDataNodes() and
>>> replicatedUnstableDataNodes()
>>> methods.
>>> 
>>> BTW, IlleagalStateException with no message is confusing.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Wed, Apr 12, 2017 at 2:36 PM, Sergi Vladykin <
>> sergi.vlady...@gmail.com>
>>> wrote:
>>> 
 Andrey,
 
 Because if you run query on replicated cache, but select data from
 a
 partitioned table, you will get only a part of the result.
 
 Igor,
 
 You are mostly right, but
 
 1. Performance characteristics may change.
 2. Ignite SQL processing pipeline may not support all the stuff in
 H2
>> SQL
 and fail in some case where it worked previously.
 
 Because of this the change may affect existing applications and I
> want
>> to
 have it in 2.0 to make it legal.
 
 Sergi
 
 2017-04-12 14:10 GMT+03:00 Igor Sapego :
 
> Also, is it really a breaking change if the results are wrong?
> To me it looks more like a bugfix, i.e. you can't break something
> that does not work properly.
> 
> Best Regards,
> Igor
> 
> On Wed, Apr 12, 2017 at 2:04 PM, Andrey Mashenkov <
> andrey.mashen...@gmail.com> wrote:
> 
>> Sergi,
>> 
>> How can query to replicated cache leads to to wrong results?
>> Is it due to we can read backup entries?
>> 
>> On Wed, Apr 12, 2017 at 12:31 PM, Sergi Vladykin <
> sergi.vlady...@gmail.com
>>> 
>> wrote:
>> 
>>> Guys,
>>> 
>>> I want to introduce another breaking change for 2.0.
>>> 
>>> Currently SQL is being processed differently when we call
> method
> `query`
>> on
>>> 

Re: Question about cache and transaction on different nodes

[Dmitriy Setrakyan]

There is no bug.

Dmitriy, you should introduce a variable:

*cache0 = grid(0).cache(null);*

Then you should use cache0 variable to do a cache put.

You cannot use transaction API from grid0 and then cache API from grid1. In
a normal environment, the cache0 and cache1 variables would not even be
present in the same JVM - they would be on different physical servers.

D.

On Wed, Apr 12, 2017 at 11:08 AM, Sergi Vladykin 
wrote:

> Looks like a bug to me.
>
> Sergi
>
> 2017-04-12 21:03 GMT+03:00 Дмитрий Рябов :
>
> > Why not? I do something with cache inside transaction. The only reason to
> > not rollback is another node?
> >
> > 2017-04-12 19:52 GMT+03:00 Andrey Mashenkov  >:
> >
> > > Hi Dmitry,
> > >
> > > Looks like you start transaction on node "grid(0)", but update value on
> > > another node "grid(1)".
> > > So, technically, it is not nested transactions, right?
> > >
> > > On Wed, Apr 12, 2017 at 7:32 PM, Дмитрий Рябов 
> > > wrote:
> > >
> > > > Hello, igniters. I start the node and create a transactional cache on
> > it,
> > > > on the other node I start the transaction and "put" in previously
> > created
> > > > cache and rollback transaction. So what should I get? Value stored
> > before
> > > > transaction or inside rolled transaction?
> > > >
> > > > public void testRollback() throws Exception {
> > > > startGrid(0);
> > > > startGrid(1);
> > > > IgniteCache cache1 = grid( 1).cache(null);
> > > > cache1.put(1, 1);
> > > > try (Transaction tx = grid(0).transactions().
> txStart(PESSIMISTIC,
> > > READ_COMMITTED)) {
> > > > cache1.put(1, );
> > > > tx.rollback();
> > > > }
> > > > assertEquals((Integer) 1, cache1.get(1));
> > > > }
> > > >
> > > >
> > > > The question is why I got  instead of 1? If it is right
> behaviour -
> > > > why it nowhere explained?
> > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > Best regards,
> > > Andrey V. Mashenkov
> > >
> >
>

Re: CREATE TABLE SQL command syntax

[Dmitriy Setrakyan]

Got it. Can we also add CONFIGURATION keyword?

On Wed, Apr 12, 2017 at 11:34 AM, Sergi Vladykin 
wrote:

> Dmitriy,
>
> H2 does not support any "user-specific" syntax and it should not. Instead
> it has a concept of Mode, which is basically a setting which allows H2 to
> be compatible with other databases. For example, some keywords that make
> sense for other databases are just ignored, but this makes the statement
> from other BD work in H2.
>
> It allows us to introduce "ApacheIgnite" mode, which will allow to add some
> minor tweaks into Parser. These tweaks will be covered by tests and no one
> will be able to just silently break our code.
>
> Actually what I see is that we do not need any custom parsing at all, all
> we need is just need a couple of minor tweaks (like AFFINITY keyword),
> other SQL must work as is. Thus trying to plug in a parser looks like an
> overkill and fragile idea a priori.
>
> Sergi
>
> 2017-04-12 20:40 GMT+03:00 Dmitriy Setrakyan :
>
> > Hm... I think the truth is somewhere in the middle here.
> >
> > The syntax proposed by Sergi makes sense to me. However, I am still
> > struggling why would H2 accept our patch, if it has AFFINITY KEY keyword
> in
> > it, which has nothing to do with H2.
> >
> > It does sound like certain portions of SQL do need to be plugable to
> > support the user-specific syntax.
> >
> > Sergi, am I missing something?
> >
> > D.
> >
> > On Wed, Apr 12, 2017 at 8:51 AM, Sergi Vladykin <
> sergi.vlady...@gmail.com>
> > wrote:
> >
> > > If it is that little, then all this copy/paste shit-coding makes no
> > sense.
> > >
> > > We have to add a respective mode to H2, add respective tests to H2, so
> > that
> > > other contributors of H2 will not occasionally break our stuff. Thats
> it.
> > >
> > > I will be the first H2 committer who will reject you patch, don't waste
> > > your time.
> > >
> > > Sergi
> > >
> > > 2017-04-12 16:33 GMT+03:00 Alexander Paschenko <
> > > alexander.a.pasche...@gmail.com>:
> > >
> > > > Sergi,
> > > >
> > > > First, it would be as little as overriding the part responsible for
> > > > CREATE TABLE - there's no need to touch anything else as luckily H2
> > > > parser is internally structured well enough.
> > > >
> > > > Second, although it is not all-around perfect, I am most confident
> > > > that this is far better than dragging into H2 bunch of stuff that
> they
> > > > don't really need just because we need it there or can smug it there.
> > > >
> > > > I think I'll just spend some time in the weekend and come up with a
> > > > prototype as otherwise this talk seems to be just a chit-chat.
> > > >
> > > > - Alex
> > > >
> > > > 2017-04-12 14:38 GMT+03:00 Sergi Vladykin  >:
> > > > > So basically in inherited class you are going co copy/paste base
> > class
> > > > > methods and tweak them? I don't like this approach.
> > > > >
> > > > > Sergi
> > > > >
> > > > > 2017-04-12 14:07 GMT+03:00 Alexander Paschenko <
> > > > > alexander.a.pasche...@gmail.com>:
> > > > >
> > > > >> Sergi,
> > > > >>
> > > > >> As I've written in my previous post, it would be just inheriting
> > > Parser
> > > > on
> > > > >> Ignite side and plugging its instance in SINGLE place. Just making
> > > H2's
> > > > >> Parser internal methods protected instead of private would let us
> do
> > > the
> > > > >> trick.
> > > > >>
> > > > >> — Alex
> > > > >>
> > > > >> среда, 12 апреля 2017 г. пользователь Sergi Vladykin написал:
> > > > >>
> > > > >> > I don't see how you make H2 Parser extendable, you will have to
> > add
> > > > >> plugin
> > > > >> > call to every *potentially* extendable place in it. In general
> > this
> > > > does
> > > > >> > not work. As H2 guy I would also reject patch like this.
> > > > >> >
> > > > >> > Sergi
> > > > >> >
> > > > >> > 2017-04-12 13:10 GMT+03:00 Alexander Paschenko <
> > > > >> > alexander.a.pasche...@gmail.com >:
> > > > >> >
> > > > >> > > Sergi,
> > > > >> > >
> > > > >> > > Please have a closer look at what I've written in my first
> > post. I
> > > > >> don't
> > > > >> > > see why we have to cling to H2 and its parsing modes all the
> > time
> > > —
> > > > >> after
> > > > >> > > all, we're just talking string processing now, aren't we?
> (Yes,
> > > > complex
> > > > >> > and
> > > > >> > > non trivial, but still.)
> > > > >> > >
> > > > >> > > What's wrong with idea of patching H2 to allow custom parsing?
> > > (With
> > > > >> the
> > > > >> > > parsing itself living in Ignite code, obviously, not in H2.).
> > > > >> > >
> > > > >> > > What I propose is just to make H2's Parser class extendable
> and
> > > > make H2
> > > > >> > > aware of its descendants via config params. And that's all
> with
> > > > respect
> > > > >> > to
> > > > >> > > H2, nothing more.
> > > > >> > >
> > > > >> > > After that, on Ignite side we do all we want with our parser
> > based
> > > > on
> > > > >> > > theirs. It resembles story with 

Re: SQL on PARTITIONED vs REPLICATED cache

[Dmitriy Setrakyan]

Denis, I think that you meant selecting from replicated cache first as an
invalid scenario, but provided the wrong example. Here is the correct
example for the invalid query:

SELECT * FROM replicatedCache … JOIN partitionedCache …”

I do agree, we should make the change, as long as we keep the flag to
enable the old behavior.

D.

On Wed, Apr 12, 2017 at 12:50 PM, Denis Magda  wrote:

> Sergi,
>
> As far as I understand you’re considering an example below:
>
> IgniteCache partitioneCache = ...;
> IgniteCache replicatedCache = …;
>
> 1. Valid scenario - *partitionedCache*.query(“SELECT * FROM
> partitionedCache … JOIN replicatedCache …”);
> 2. Error-prone scenario - *replicatedCache*.query(“SELECT * FROM
> partitionedCache … JOIN replicatedCache …”);
>
> Do you mean 2. as the issue? If it’s so then can’t we just detect on our
> own that all the caches are replicated and execute a query more optimal?
> This should omit necessity to add isReplicatedOnly()?
>
> —
> Denis
>
> > On Apr 12, 2017, at 7:07 AM, Andrey Mashenkov <
> andrey.mashen...@gmail.com> wrote:
> >
> > Yes, it's reasonable.
> >
> > On Wed, Apr 12, 2017 at 3:23 PM, Sergi Vladykin <
> sergi.vlady...@gmail.com>
> > wrote:
> >
> >> Good point, but I'm not sure. The difference is that on client node you
> >> should not be able to enable isLocal, while isReplicatedOnly is
> perfectly
> >> valid. What do you think?
> >>
> >> Sergi
> >>
> >> 2017-04-12 15:18 GMT+03:00 Andrey Mashenkov  >:
> >>
> >>> Sergi,
> >>>
> >>> Got it.
> >>>
> >>> Does query execution way and results will be same for isReplicatedOnly
> >> flag
> >>> and for isLocal flag turned on?
> >>> If my understanding is correct, we will get same results and there is
> no
> >>> need to introduce a new flag.
> >>>
> >>>
> >>>
> >>> On Wed, Apr 12, 2017 at 2:54 PM, Sergi Vladykin <
> >> sergi.vlady...@gmail.com>
> >>> wrote:
> >>>
>  Ok, let it be an exception. I'm just saying that the thing does not
> >> work
>  now.
> 
>  Sergi
> 
>  2017-04-12 14:50 GMT+03:00 Andrey Mashenkov <
> >> andrey.mashen...@gmail.com
>  :
> 
> > Sergi,
> >
> > I wounder how it is possible?
> >
> > Looks like it is impossible to run query on replicated cache, but
> >>> select
> > data from a
> > partitioned table. It will result with IlleagalStateException on
> >> stable
> > topology or
> > IgniteCacheException on unstable topology.
> > See ReduceQueryExecutor.stableDataNodes() and
> > replicatedUnstableDataNodes()
> > methods.
> >
> > BTW, IlleagalStateException with no message is confusing.
> >
> >
> >
> >
> >
> > On Wed, Apr 12, 2017 at 2:36 PM, Sergi Vladykin <
>  sergi.vlady...@gmail.com>
> > wrote:
> >
> >> Andrey,
> >>
> >> Because if you run query on replicated cache, but select data from
> >> a
> >> partitioned table, you will get only a part of the result.
> >>
> >> Igor,
> >>
> >> You are mostly right, but
> >>
> >> 1. Performance characteristics may change.
> >> 2. Ignite SQL processing pipeline may not support all the stuff in
> >> H2
>  SQL
> >> and fail in some case where it worked previously.
> >>
> >> Because of this the change may affect existing applications and I
> >>> want
>  to
> >> have it in 2.0 to make it legal.
> >>
> >> Sergi
> >>
> >> 2017-04-12 14:10 GMT+03:00 Igor Sapego :
> >>
> >>> Also, is it really a breaking change if the results are wrong?
> >>> To me it looks more like a bugfix, i.e. you can't break something
> >>> that does not work properly.
> >>>
> >>> Best Regards,
> >>> Igor
> >>>
> >>> On Wed, Apr 12, 2017 at 2:04 PM, Andrey Mashenkov <
> >>> andrey.mashen...@gmail.com> wrote:
> >>>
>  Sergi,
> 
>  How can query to replicated cache leads to to wrong results?
>  Is it due to we can read backup entries?
> 
>  On Wed, Apr 12, 2017 at 12:31 PM, Sergi Vladykin <
> >>> sergi.vlady...@gmail.com
> >
>  wrote:
> 
> > Guys,
> >
> > I want to introduce another breaking change for 2.0.
> >
> > Currently SQL is being processed differently when we call
> >>> method
> >>> `query`
>  on
> > partitioned cache and on replicated: on replicated cache we
> >> do
>  not
> > do
> >>> any
> > extra processing and execute the query as is on current node.
> >
> > This behavior historically existed for performance reasons.
> >> But
>  it
> > is
> >>> not
> > obvious and leads to wrong query results. This issue becomes
> >>> even
> >> more
> > creepy with JDBC and ODBC drivers.
> >
> > In 2.0 I want to execute all the SQL queries the same way
> >>> through
> > 

Re: Adding ML to Ignite, IGNITE-4572

[Yury Babak]

As far as I know Nikita wants to provide this documentation.



--
View this message in context: 
http://apache-ignite-developers.2346864.n4.nabble.com/Adding-ML-to-Ignite-IGNITE-4572-tp13936p16542.html
Sent from the Apache Ignite Developers mailing list archive at Nabble.com.

Re: SQL on PARTITIONED vs REPLICATED cache

[Denis Magda]

Sergi,

As far as I understand you’re considering an example below:

IgniteCache partitioneCache = ...;
IgniteCache replicatedCache = …;

1. Valid scenario - *partitionedCache*.query(“SELECT * FROM partitionedCache … 
JOIN replicatedCache …”);
2. Error-prone scenario - *replicatedCache*.query(“SELECT * FROM 
partitionedCache … JOIN replicatedCache …”);

Do you mean 2. as the issue? If it’s so then can’t we just detect on our own 
that all the caches are replicated and execute a query more optimal? This 
should omit necessity to add isReplicatedOnly()?

—
Denis

> On Apr 12, 2017, at 7:07 AM, Andrey Mashenkov  
> wrote:
> 
> Yes, it's reasonable.
> 
> On Wed, Apr 12, 2017 at 3:23 PM, Sergi Vladykin 
> wrote:
> 
>> Good point, but I'm not sure. The difference is that on client node you
>> should not be able to enable isLocal, while isReplicatedOnly is perfectly
>> valid. What do you think?
>> 
>> Sergi
>> 
>> 2017-04-12 15:18 GMT+03:00 Andrey Mashenkov :
>> 
>>> Sergi,
>>> 
>>> Got it.
>>> 
>>> Does query execution way and results will be same for isReplicatedOnly
>> flag
>>> and for isLocal flag turned on?
>>> If my understanding is correct, we will get same results and there is no
>>> need to introduce a new flag.
>>> 
>>> 
>>> 
>>> On Wed, Apr 12, 2017 at 2:54 PM, Sergi Vladykin <
>> sergi.vlady...@gmail.com>
>>> wrote:
>>> 
 Ok, let it be an exception. I'm just saying that the thing does not
>> work
 now.
 
 Sergi
 
 2017-04-12 14:50 GMT+03:00 Andrey Mashenkov <
>> andrey.mashen...@gmail.com
 :
 
> Sergi,
> 
> I wounder how it is possible?
> 
> Looks like it is impossible to run query on replicated cache, but
>>> select
> data from a
> partitioned table. It will result with IlleagalStateException on
>> stable
> topology or
> IgniteCacheException on unstable topology.
> See ReduceQueryExecutor.stableDataNodes() and
> replicatedUnstableDataNodes()
> methods.
> 
> BTW, IlleagalStateException with no message is confusing.
> 
> 
> 
> 
> 
> On Wed, Apr 12, 2017 at 2:36 PM, Sergi Vladykin <
 sergi.vlady...@gmail.com>
> wrote:
> 
>> Andrey,
>> 
>> Because if you run query on replicated cache, but select data from
>> a
>> partitioned table, you will get only a part of the result.
>> 
>> Igor,
>> 
>> You are mostly right, but
>> 
>> 1. Performance characteristics may change.
>> 2. Ignite SQL processing pipeline may not support all the stuff in
>> H2
 SQL
>> and fail in some case where it worked previously.
>> 
>> Because of this the change may affect existing applications and I
>>> want
 to
>> have it in 2.0 to make it legal.
>> 
>> Sergi
>> 
>> 2017-04-12 14:10 GMT+03:00 Igor Sapego :
>> 
>>> Also, is it really a breaking change if the results are wrong?
>>> To me it looks more like a bugfix, i.e. you can't break something
>>> that does not work properly.
>>> 
>>> Best Regards,
>>> Igor
>>> 
>>> On Wed, Apr 12, 2017 at 2:04 PM, Andrey Mashenkov <
>>> andrey.mashen...@gmail.com> wrote:
>>> 
 Sergi,
 
 How can query to replicated cache leads to to wrong results?
 Is it due to we can read backup entries?
 
 On Wed, Apr 12, 2017 at 12:31 PM, Sergi Vladykin <
>>> sergi.vlady...@gmail.com
> 
 wrote:
 
> Guys,
> 
> I want to introduce another breaking change for 2.0.
> 
> Currently SQL is being processed differently when we call
>>> method
>>> `query`
 on
> partitioned cache and on replicated: on replicated cache we
>> do
 not
> do
>>> any
> extra processing and execute the query as is on current node.
> 
> This behavior historically existed for performance reasons.
>> But
 it
> is
>>> not
> obvious and leads to wrong query results. This issue becomes
>>> even
>> more
> creepy with JDBC and ODBC drivers.
> 
> In 2.0 I want to execute all the SQL queries the same way
>>> through
> the
 whole
> processing pipeline to guaranty the correct result
>>> irrespectively
> to
>>> the
> cache that was the query originator.
> 
> To be able to have the old behavior (skip all the
>> preprocessing
 and
>> run
> query on current node) add a flag isReplicatedOnly() on
>>> SqlQuery
> and
> SqlFieldsQuery. It will be disabled by default and if one
>> knows
> that
>>> the
> only replicated tables participate in a query, then he can
>>> enable
> it
>>> for
> better performance.
> 
> Sergi
> 
 
 
 
 --
 

[jira] [Created] (IGNITE-4954) Timeout in ignite-cassandra SessionPool is not configurable

[Valentin Kulichenko (JIRA)]

Valentin Kulichenko created IGNITE-4954:
---

 Summary: Timeout in ignite-cassandra SessionPool is not 
configurable
 Key: IGNITE-4954
 URL: https://issues.apache.org/jira/browse/IGNITE-4954
 Project: Ignite
  Issue Type: Bug
  Components: ignite-cassandra
Affects Versions: 1.9
Reporter: Valentin Kulichenko
Assignee: Valentin Kulichenko
Priority: Critical
 Fix For: 2.0


Cassandra cache store implementation uses {{SessionPool}} class which kills 
idle sessions after 5 minutes. Need to make this timeout configurable.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: IGNITE-2766 Spring Cache Manager ReConnect Issue

[Valentin Kulichenko]

Rishi,

I don't think listening to event and OOME can be related to each other.
Please investigate what is consuming memory.

-Val

On Wed, Apr 12, 2017 at 6:20 PM, Rishi Yagnik  wrote:

> Hi Val,
>
> Just want to share my experience here -
>
> with the code changes I suggested we run into issue,out of memory on ignite
> with ignite thread whenever ignite cluster looses the client connection (
> we had a cluster with multicast communication) .
>
>
> However, we changed our cluster with ip based configuration few days back
> and hoping that solves our issues.
>
> Do you still think that listening events on spring cache manager is a good
> design here ?
>
> will await for your feedback..
>
> Thanks,
>
> On Fri, Mar 31, 2017 at 11:51 PM, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > Hi Rishi,
> >
> > I looked at your changes and added a comment in the ticket.
> >
> > -Val
> >
> > On Wed, Mar 29, 2017 at 10:04 AM, Valentin Kulichenko <
> > valentin.kuliche...@gmail.com> wrote:
> >
> > > Hi Rishi,
> > >
> > > I will review in next couple of days.
> > >
> > > -Val
> > >
> > > On Tue, Mar 28, 2017 at 8:24 PM, Rishi Yagnik 
> > > wrote:
> > >
> > >> Hi Val,
> > >>
> > >> Committed changes on IGNITE-2786, would like you to review the
> > >> changes.Would you please review it ?
> > >>
> > >> Thanks,
> > >>
> > >> On Mon, Mar 27, 2017 at 6:11 PM, Valentin Kulichenko <
> > >> valentin.kuliche...@gmail.com> wrote:
> > >>
> > >> > Rishi,
> > >> >
> > >> > You should be able to assign to tickets to yourself now.
> > >> >
> > >> > -Val
> > >> >
> > >> > On Mon, Mar 27, 2017 at 1:23 PM, Rishi Yagnik <
> rishiyag...@gmail.com>
> > >> > wrote:
> > >> >
> > >> > > Hi Val,
> > >> > >
> > >> > > My user name is ryagnik
> > >> > >
> > >> > > Thanks,
> > >> > > Rishi
> > >> > >
> > >> > > On Mon, Mar 27, 2017 at 12:14 PM, Valentin Kulichenko <
> > >> > > valentin.kuliche...@gmail.com> wrote:
> > >> > >
> > >> > > > Hi Rishi,
> > >> > > >
> > >> > > > What is your username in Jira? I will add you as a contributor.
> > >> > > >
> > >> > > > Also please go through [1] and [2] for all the details about our
> > >> > process.
> > >> > > >
> > >> > > > [1] https://ignite.apache.org/community/contribute.html#
> > contribute
> > >> > > > [2] https://cwiki.apache.org/confluence/display/IGNITE/
> > >> > > Development+Process
> > >> > > >
> > >> > > > -Val
> > >> > > >
> > >> > > > On Sun, Mar 26, 2017 at 5:56 PM, Rishi Yagnik <
> > >> rishiyag...@gmail.com>
> > >> > > > wrote:
> > >> > > >
> > >> > > > > Hi Val,
> > >> > > > >
> > >> > > > > I started working on it but could not assign issue to me, how
> > do I
> > >> > > assign
> > >> > > > > ticket to my self ?
> > >> > > > >
> > >> > > > > Do I need contributor access to contribute the fix ?
> > >> > > > >
> > >> > > > > Please clarify..
> > >> > > > >
> > >> > > > > Thanks,
> > >> > > > >
> > >> > > > > On Fri, Mar 24, 2017 at 12:10 AM, Rishi Yagnik <
> > >> > rishiyag...@gmail.com>
> > >> > > > > wrote:
> > >> > > > >
> > >> > > > > > Hi Val,
> > >> > > > > >
> > >> > > > > > Sorry for the delay, I will work on the fix on weekend.
> > >> > > > > >
> > >> > > > > > Thanks,
> > >> > > > > >
> > >> > > > > >
> > >> > > > > > On Mon, Mar 13, 2017 at 12:08 PM, Rishi Yagnik <
> > >> > > rishiyag...@gmail.com>
> > >> > > > > > wrote:
> > >> > > > > >
> > >> > > > > >> Hi Val,
> > >> > > > > >>
> > >> > > > > >> I will work on it in my spare time..
> > >> > > > > >>
> > >> > > > > >> Take Care,
> > >> > > > > >> Rishi
> > >> > > > > >>
> > >> > > > > >> > On Mar 13, 2017, at 10:54 AM, Valentin Kulichenko <
> > >> > > > > >> valentin.kuliche...@gmail.com> wrote:
> > >> > > > > >> >
> > >> > > > > >> > Hi Rishi,
> > >> > > > > >> >
> > >> > > > > >> > Can you please assign the ticket to yourself and create a
> > >> pull
> > >> > > > request
> > >> > > > > >> as
> > >> > > > > >> > described in [1]?
> > >> > > > > >> >
> > >> > > > > >> > Let's follow the process :)
> > >> > > > > >> >
> > >> > > > > >> > [1] https://cwiki.apache.org/confl
> > >> uence/display/IGNITE/How+to+
> > >> > > > > >> Contribute
> > >> > > > > >> >
> > >> > > > > >> > -Val
> > >> > > > > >> >
> > >> > > > > >> > On Sun, Mar 12, 2017 at 2:04 AM, ignite_dev2017 <
> > >> > > > > rishiyag...@gmail.com>
> > >> > > > > >> > wrote:
> > >> > > > > >> >
> > >> > > > > >> >> Hi Val,
> > >> > > > > >> >>
> > >> > > > > >> >> The fix which we applied as follows with
> > SpringCacheManager
> > >> -
> > >> > > > > >> >>
> > >> > > > > >> >> 1) Design was to listen for ignite re connect event
> > >> > > > > >> >> 2) And clear the cache on reconnect
> > >> > > > > >> >>
> > >> > > > > >> >> See the following code below and let us know if this is
> > >> > helpful -
> > >> > > > > >> >>
> > >> > > > > >> >> In afterPropertiesSet -
> > >> > > > > >> >>
> > >> > > > > >> >> //Handles the reconnect event, on server crashes OR
> > network
> > >> > > > failure,
> > >> > > > > 

Re: Adding ML to Ignite, IGNITE-4572

[Yury Babak]

Guys, a bit more details about the current state of ML lib and how we plan to
release it.

Currently IgniteML is separate module and use java8. We depends only on
ignite-core module. So we think that we could release lib as sources. It
should be much easier than provide our lib binary.



--
View this message in context: 
http://apache-ignite-developers.2346864.n4.nabble.com/Adding-ML-to-Ignite-IGNITE-4572-tp13936p16532.html
Sent from the Apache Ignite Developers mailing list archive at Nabble.com.

Re: Question about cache and transaction on different nodes

[Sergi Vladykin]

Looks like a bug to me.

Sergi

2017-04-12 21:03 GMT+03:00 Дмитрий Рябов :

> Why not? I do something with cache inside transaction. The only reason to
> not rollback is another node?
>
> 2017-04-12 19:52 GMT+03:00 Andrey Mashenkov :
>
> > Hi Dmitry,
> >
> > Looks like you start transaction on node "grid(0)", but update value on
> > another node "grid(1)".
> > So, technically, it is not nested transactions, right?
> >
> > On Wed, Apr 12, 2017 at 7:32 PM, Дмитрий Рябов 
> > wrote:
> >
> > > Hello, igniters. I start the node and create a transactional cache on
> it,
> > > on the other node I start the transaction and "put" in previously
> created
> > > cache and rollback transaction. So what should I get? Value stored
> before
> > > transaction or inside rolled transaction?
> > >
> > > public void testRollback() throws Exception {
> > > startGrid(0);
> > > startGrid(1);
> > > IgniteCache cache1 = grid( 1).cache(null);
> > > cache1.put(1, 1);
> > > try (Transaction tx = grid(0).transactions().txStart(PESSIMISTIC,
> > READ_COMMITTED)) {
> > > cache1.put(1, );
> > > tx.rollback();
> > > }
> > > assertEquals((Integer) 1, cache1.get(1));
> > > }
> > >
> > >
> > > The question is why I got  instead of 1? If it is right behaviour -
> > > why it nowhere explained?
> > >
> > >
> > >
> >
> >
> > --
> > Best regards,
> > Andrey V. Mashenkov
> >
>

Re: Question about cache and transaction on different nodes

[Дмитрий Рябов]

Why not? I do something with cache inside transaction. The only reason to
not rollback is another node?

2017-04-12 19:52 GMT+03:00 Andrey Mashenkov :

> Hi Dmitry,
>
> Looks like you start transaction on node "grid(0)", but update value on
> another node "grid(1)".
> So, technically, it is not nested transactions, right?
>
> On Wed, Apr 12, 2017 at 7:32 PM, Дмитрий Рябов 
> wrote:
>
> > Hello, igniters. I start the node and create a transactional cache on it,
> > on the other node I start the transaction and "put" in previously created
> > cache and rollback transaction. So what should I get? Value stored before
> > transaction or inside rolled transaction?
> >
> > public void testRollback() throws Exception {
> > startGrid(0);
> > startGrid(1);
> > IgniteCache cache1 = grid( 1).cache(null);
> > cache1.put(1, 1);
> > try (Transaction tx = grid(0).transactions().txStart(PESSIMISTIC,
> READ_COMMITTED)) {
> > cache1.put(1, );
> > tx.rollback();
> > }
> > assertEquals((Integer) 1, cache1.get(1));
> > }
> >
> >
> > The question is why I got  instead of 1? If it is right behaviour -
> > why it nowhere explained?
> >
> >
> >
>
>
> --
> Best regards,
> Andrey V. Mashenkov
>

Re: CREATE TABLE SQL command syntax

[Dmitriy Setrakyan]

Hm... I think the truth is somewhere in the middle here.

The syntax proposed by Sergi makes sense to me. However, I am still
struggling why would H2 accept our patch, if it has AFFINITY KEY keyword in
it, which has nothing to do with H2.

It does sound like certain portions of SQL do need to be plugable to
support the user-specific syntax.

Sergi, am I missing something?

D.

On Wed, Apr 12, 2017 at 8:51 AM, Sergi Vladykin 
wrote:

> If it is that little, then all this copy/paste shit-coding makes no sense.
>
> We have to add a respective mode to H2, add respective tests to H2, so that
> other contributors of H2 will not occasionally break our stuff. Thats it.
>
> I will be the first H2 committer who will reject you patch, don't waste
> your time.
>
> Sergi
>
> 2017-04-12 16:33 GMT+03:00 Alexander Paschenko <
> alexander.a.pasche...@gmail.com>:
>
> > Sergi,
> >
> > First, it would be as little as overriding the part responsible for
> > CREATE TABLE - there's no need to touch anything else as luckily H2
> > parser is internally structured well enough.
> >
> > Second, although it is not all-around perfect, I am most confident
> > that this is far better than dragging into H2 bunch of stuff that they
> > don't really need just because we need it there or can smug it there.
> >
> > I think I'll just spend some time in the weekend and come up with a
> > prototype as otherwise this talk seems to be just a chit-chat.
> >
> > - Alex
> >
> > 2017-04-12 14:38 GMT+03:00 Sergi Vladykin :
> > > So basically in inherited class you are going co copy/paste base class
> > > methods and tweak them? I don't like this approach.
> > >
> > > Sergi
> > >
> > > 2017-04-12 14:07 GMT+03:00 Alexander Paschenko <
> > > alexander.a.pasche...@gmail.com>:
> > >
> > >> Sergi,
> > >>
> > >> As I've written in my previous post, it would be just inheriting
> Parser
> > on
> > >> Ignite side and plugging its instance in SINGLE place. Just making
> H2's
> > >> Parser internal methods protected instead of private would let us do
> the
> > >> trick.
> > >>
> > >> — Alex
> > >>
> > >> среда, 12 апреля 2017 г. пользователь Sergi Vladykin написал:
> > >>
> > >> > I don't see how you make H2 Parser extendable, you will have to add
> > >> plugin
> > >> > call to every *potentially* extendable place in it. In general this
> > does
> > >> > not work. As H2 guy I would also reject patch like this.
> > >> >
> > >> > Sergi
> > >> >
> > >> > 2017-04-12 13:10 GMT+03:00 Alexander Paschenko <
> > >> > alexander.a.pasche...@gmail.com >:
> > >> >
> > >> > > Sergi,
> > >> > >
> > >> > > Please have a closer look at what I've written in my first post. I
> > >> don't
> > >> > > see why we have to cling to H2 and its parsing modes all the time
> —
> > >> after
> > >> > > all, we're just talking string processing now, aren't we? (Yes,
> > complex
> > >> > and
> > >> > > non trivial, but still.)
> > >> > >
> > >> > > What's wrong with idea of patching H2 to allow custom parsing?
> (With
> > >> the
> > >> > > parsing itself living in Ignite code, obviously, not in H2.).
> > >> > >
> > >> > > What I propose is just to make H2's Parser class extendable and
> > make H2
> > >> > > aware of its descendants via config params. And that's all with
> > respect
> > >> > to
> > >> > > H2, nothing more.
> > >> > >
> > >> > > After that, on Ignite side we do all we want with our parser based
> > on
> > >> > > theirs. It resembles story with custom types — first we make H2
> > >> > extendable
> > >> > > in the way we need, then we introduce exact features we need on
> > Ignite
> > >> > > side.
> > >> > >
> > >> > > — Alex
> > >> > >
> > >> > > среда, 12 апреля 2017 г. пользователь Sergi Vladykin написал:
> > >> > >
> > >> > > > It definitely makes sense to add a separate mode for Ignite in
> H2.
> > >> > Though
> > >> > > > it is wrong to think that it will allow us to add any crazy
> > syntax we
> > >> > > want
> > >> > > > (and it is actually a wrong idea imo), only the minor variations
> > of
> > >> the
> > >> > > > existing syntax. But this must be enough.
> > >> > > >
> > >> > > > I believe we should end up with something like
> > >> > > >
> > >> > > > CREATE TABLE person
> > >> > > > (
> > >> > > >   id INT PRIMARY KEY,
> > >> > > >   orgId INT AFFINITY KEY,
> > >> > > >   name VARCHAR
> > >> > > > )
> > >> > > > WITH "cfg:my_config_template.xml"
> > >> > > >
> > >> > > > Sergi
> > >> > > >
> > >> > > >
> > >> > > > 2017-04-12 7:54 GMT+03:00 Dmitriy Setrakyan <
> > dsetrak...@apache.org
> > >> > 
> > >> > > > >:
> > >> > > >
> > >> > > > > Agree, the updated syntax looks better. One change though: KEY
> > ->
> > >> > > PRIMARY
> > >> > > > > KEY.
> > >> > > > >
> > >> > > > > Sergi, what do you think?
> > >> > > > >
> > >> > > > > D.
> > >> > > > >
> > >> > > > > On Tue, Apr 11, 2017 at 9:50 PM, Pavel Tupitsyn <
> > >> > ptupit...@apache.org 
> > >> > > > 

Re: Question about cache and transaction on different nodes

[Andrey Mashenkov]

Hi Dmitry,

Looks like you start transaction on node "grid(0)", but update value on
another node "grid(1)".
So, technically, it is not nested transactions, right?

On Wed, Apr 12, 2017 at 7:32 PM, Дмитрий Рябов 
wrote:

> Hello, igniters. I start the node and create a transactional cache on it,
> on the other node I start the transaction and "put" in previously created
> cache and rollback transaction. So what should I get? Value stored before
> transaction or inside rolled transaction?
>
> public void testRollback() throws Exception {
> startGrid(0);
> startGrid(1);
> IgniteCache cache1 = grid( 1).cache(null);
> cache1.put(1, 1);
> try (Transaction tx = grid(0).transactions().txStart(PESSIMISTIC, 
> READ_COMMITTED)) {
> cache1.put(1, );
> tx.rollback();
> }
> assertEquals((Integer) 1, cache1.get(1));
> }
>
>
> The question is why I got  instead of 1? If it is right behaviour -
> why it nowhere explained?
>
>
>


-- 
Best regards,
Andrey V. Mashenkov

[GitHub] ignite pull request #1782: IGNITE-3581: CPP: Moved enums to separate structs

[isapego]

GitHub user isapego opened a pull request:

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

IGNITE-3581: CPP: Moved enums to separate structs



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

$ git pull https://github.com/gridgain/apache-ignite ignite-3581

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

https://github.com/apache/ignite/pull/1782.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 #1782


commit 1fd053e9ff683cb8f82d7fc4f5f8ab97c60ec031
Author: Igor Sapego 
Date:   2017-04-11T10:42:23Z

IGNITE-3581: Moved enums to separate structs for Core

commit 54f1cc311524edc099cc8fb0e580c5dfb75a5842
Author: Igor Sapego 
Date:   2017-04-12T14:19:01Z

IGNITE-3581: Implemented for enums from ODBC

commit b4469927c393fe9cc7db8c839e827c7ad29215f5
Author: Igor Sapego 
Date:   2017-04-12T15:05:05Z

IGNITE-3581: Renaming




---
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.
---

Question about cache and transaction on different nodes

[Дмитрий Рябов]

Hello, igniters. I start the node and create a transactional cache on it,
on the other node I start the transaction and "put" in previously created
cache and rollback transaction. So what should I get? Value stored before
transaction or inside rolled transaction?

public void testRollback() throws Exception {
startGrid(0);
startGrid(1);
IgniteCache cache1 = grid( 1).cache(null);
cache1.put(1, 1);
try (Transaction tx = grid(0).transactions().txStart(PESSIMISTIC,
READ_COMMITTED)) {
cache1.put(1, );
tx.rollback();
}
assertEquals((Integer) 1, cache1.get(1));
}


The question is why I got  instead of 1? If it is right behaviour - why
it nowhere explained?

Re: ignite-3682 - GridFunc: move all inner anonymous classes to separate top-level classes.

[Vyacheslav Daradur]

Andrey,

I see you've merged it before I fixed merge conflict and you fixed it
yourself, thank you)

There is one more unused method:
public static  Map
viewReadOnly

You can see it in my fixed version:
https://github.com/apache/ignite/pull/1652/files

BTW, looks unusually that the master-branch contains separate commits of
this task.


2017-04-12 19:13 GMT+03:00 Andrey Gura :

> Vyacheslav,
>
> thank you for contribution! Your changes are merged into master branch.
>
> On Mon, Mar 20, 2017 at 1:11 PM, Vyacheslav Daradur 
> wrote:
> > I've received answers in the issue.
> >
> > Ready for review.
> >
> > 2017-03-16 10:14 GMT+03:00 Vyacheslav Daradur :
> >
> >> Hello everyone.
> >>
> >> I have some questions about the issue https://issues.apache.
> >> org/jira/browse/IGNITE-3682
> >>
> >> 1) Can I do some minor refactoring of GridFunc class within this task?
> >> (to remove unused methods and code duplicates)
> >> Or just to extract anonymous classes?
> >>
> >> 2) Should @Depricated be added to GridFunc and F classes?
> >>
> >> --
> >> Best Regards, Vyacheslav
> >>
> >
> >
> >
> > --
> > Best Regards, Vyacheslav
>



-- 
Best Regards, Vyacheslav

Re: IGNITE-2766 Spring Cache Manager ReConnect Issue

[Rishi Yagnik]

Hi Val,

Just want to share my experience here -

with the code changes I suggested we run into issue,out of memory on ignite
with ignite thread whenever ignite cluster looses the client connection (
we had a cluster with multicast communication) .


However, we changed our cluster with ip based configuration few days back
and hoping that solves our issues.

Do you still think that listening events on spring cache manager is a good
design here ?

will await for your feedback..

Thanks,

On Fri, Mar 31, 2017 at 11:51 PM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Hi Rishi,
>
> I looked at your changes and added a comment in the ticket.
>
> -Val
>
> On Wed, Mar 29, 2017 at 10:04 AM, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > Hi Rishi,
> >
> > I will review in next couple of days.
> >
> > -Val
> >
> > On Tue, Mar 28, 2017 at 8:24 PM, Rishi Yagnik 
> > wrote:
> >
> >> Hi Val,
> >>
> >> Committed changes on IGNITE-2786, would like you to review the
> >> changes.Would you please review it ?
> >>
> >> Thanks,
> >>
> >> On Mon, Mar 27, 2017 at 6:11 PM, Valentin Kulichenko <
> >> valentin.kuliche...@gmail.com> wrote:
> >>
> >> > Rishi,
> >> >
> >> > You should be able to assign to tickets to yourself now.
> >> >
> >> > -Val
> >> >
> >> > On Mon, Mar 27, 2017 at 1:23 PM, Rishi Yagnik 
> >> > wrote:
> >> >
> >> > > Hi Val,
> >> > >
> >> > > My user name is ryagnik
> >> > >
> >> > > Thanks,
> >> > > Rishi
> >> > >
> >> > > On Mon, Mar 27, 2017 at 12:14 PM, Valentin Kulichenko <
> >> > > valentin.kuliche...@gmail.com> wrote:
> >> > >
> >> > > > Hi Rishi,
> >> > > >
> >> > > > What is your username in Jira? I will add you as a contributor.
> >> > > >
> >> > > > Also please go through [1] and [2] for all the details about our
> >> > process.
> >> > > >
> >> > > > [1] https://ignite.apache.org/community/contribute.html#
> contribute
> >> > > > [2] https://cwiki.apache.org/confluence/display/IGNITE/
> >> > > Development+Process
> >> > > >
> >> > > > -Val
> >> > > >
> >> > > > On Sun, Mar 26, 2017 at 5:56 PM, Rishi Yagnik <
> >> rishiyag...@gmail.com>
> >> > > > wrote:
> >> > > >
> >> > > > > Hi Val,
> >> > > > >
> >> > > > > I started working on it but could not assign issue to me, how
> do I
> >> > > assign
> >> > > > > ticket to my self ?
> >> > > > >
> >> > > > > Do I need contributor access to contribute the fix ?
> >> > > > >
> >> > > > > Please clarify..
> >> > > > >
> >> > > > > Thanks,
> >> > > > >
> >> > > > > On Fri, Mar 24, 2017 at 12:10 AM, Rishi Yagnik <
> >> > rishiyag...@gmail.com>
> >> > > > > wrote:
> >> > > > >
> >> > > > > > Hi Val,
> >> > > > > >
> >> > > > > > Sorry for the delay, I will work on the fix on weekend.
> >> > > > > >
> >> > > > > > Thanks,
> >> > > > > >
> >> > > > > >
> >> > > > > > On Mon, Mar 13, 2017 at 12:08 PM, Rishi Yagnik <
> >> > > rishiyag...@gmail.com>
> >> > > > > > wrote:
> >> > > > > >
> >> > > > > >> Hi Val,
> >> > > > > >>
> >> > > > > >> I will work on it in my spare time..
> >> > > > > >>
> >> > > > > >> Take Care,
> >> > > > > >> Rishi
> >> > > > > >>
> >> > > > > >> > On Mar 13, 2017, at 10:54 AM, Valentin Kulichenko <
> >> > > > > >> valentin.kuliche...@gmail.com> wrote:
> >> > > > > >> >
> >> > > > > >> > Hi Rishi,
> >> > > > > >> >
> >> > > > > >> > Can you please assign the ticket to yourself and create a
> >> pull
> >> > > > request
> >> > > > > >> as
> >> > > > > >> > described in [1]?
> >> > > > > >> >
> >> > > > > >> > Let's follow the process :)
> >> > > > > >> >
> >> > > > > >> > [1] https://cwiki.apache.org/confl
> >> uence/display/IGNITE/How+to+
> >> > > > > >> Contribute
> >> > > > > >> >
> >> > > > > >> > -Val
> >> > > > > >> >
> >> > > > > >> > On Sun, Mar 12, 2017 at 2:04 AM, ignite_dev2017 <
> >> > > > > rishiyag...@gmail.com>
> >> > > > > >> > wrote:
> >> > > > > >> >
> >> > > > > >> >> Hi Val,
> >> > > > > >> >>
> >> > > > > >> >> The fix which we applied as follows with
> SpringCacheManager
> >> -
> >> > > > > >> >>
> >> > > > > >> >> 1) Design was to listen for ignite re connect event
> >> > > > > >> >> 2) And clear the cache on reconnect
> >> > > > > >> >>
> >> > > > > >> >> See the following code below and let us know if this is
> >> > helpful -
> >> > > > > >> >>
> >> > > > > >> >> In afterPropertiesSet -
> >> > > > > >> >>
> >> > > > > >> >> //Handles the reconnect event, on server crashes OR
> network
> >> > > > failure,
> >> > > > > >> client
> >> > > > > >> >> connects to server and
> >> > > > > >> >>// destroy the cache
> >> > > > > >> >>IgnitePredicate lsnr = iEvt -> {
> >> > > > > >> >>LOGGER.info("Received discovery event [iEvt=" +
> >> > > > > iEvt.name()
> >> > > > > >> +
> >> > > > > >> >> ",
> >> > > > > >> >> discovery=" + iEvt.shortDisplay() + ']');
> >> > > > > >> >>
> >> > > > > >> >>caches.keySet().forEach(key -> {
> >> > > > > >> >>ignite.destroyCache(key);
> >> > > > > >> >> 

[GitHub] ignite pull request #1702: Ignite 4587

[agura]

Github user agura closed the pull request at:

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


---
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 #1660: Ignite 4587 tmp

[agura]

Github user agura closed the pull request at:

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


---
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 #1771: Ignite 3682 review

[agura]

Github user agura closed the pull request at:

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


---
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: ignite-3682 - GridFunc: move all inner anonymous classes to separate top-level classes.

[Andrey Gura]

Vyacheslav,

thank you for contribution! Your changes are merged into master branch.

On Mon, Mar 20, 2017 at 1:11 PM, Vyacheslav Daradur  wrote:
> I've received answers in the issue.
>
> Ready for review.
>
> 2017-03-16 10:14 GMT+03:00 Vyacheslav Daradur :
>
>> Hello everyone.
>>
>> I have some questions about the issue https://issues.apache.
>> org/jira/browse/IGNITE-3682
>>
>> 1) Can I do some minor refactoring of GridFunc class within this task?
>> (to remove unused methods and code duplicates)
>> Or just to extract anonymous classes?
>>
>> 2) Should @Depricated be added to GridFunc and F classes?
>>
>> --
>> Best Regards, Vyacheslav
>>
>
>
>
> --
> Best Regards, Vyacheslav

Re: CREATE TABLE SQL command syntax

[Sergi Vladykin]

If it is that little, then all this copy/paste shit-coding makes no sense.

We have to add a respective mode to H2, add respective tests to H2, so that
other contributors of H2 will not occasionally break our stuff. Thats it.

I will be the first H2 committer who will reject you patch, don't waste
your time.

Sergi

2017-04-12 16:33 GMT+03:00 Alexander Paschenko <
alexander.a.pasche...@gmail.com>:

> Sergi,
>
> First, it would be as little as overriding the part responsible for
> CREATE TABLE - there's no need to touch anything else as luckily H2
> parser is internally structured well enough.
>
> Second, although it is not all-around perfect, I am most confident
> that this is far better than dragging into H2 bunch of stuff that they
> don't really need just because we need it there or can smug it there.
>
> I think I'll just spend some time in the weekend and come up with a
> prototype as otherwise this talk seems to be just a chit-chat.
>
> - Alex
>
> 2017-04-12 14:38 GMT+03:00 Sergi Vladykin :
> > So basically in inherited class you are going co copy/paste base class
> > methods and tweak them? I don't like this approach.
> >
> > Sergi
> >
> > 2017-04-12 14:07 GMT+03:00 Alexander Paschenko <
> > alexander.a.pasche...@gmail.com>:
> >
> >> Sergi,
> >>
> >> As I've written in my previous post, it would be just inheriting Parser
> on
> >> Ignite side and plugging its instance in SINGLE place. Just making H2's
> >> Parser internal methods protected instead of private would let us do the
> >> trick.
> >>
> >> — Alex
> >>
> >> среда, 12 апреля 2017 г. пользователь Sergi Vladykin написал:
> >>
> >> > I don't see how you make H2 Parser extendable, you will have to add
> >> plugin
> >> > call to every *potentially* extendable place in it. In general this
> does
> >> > not work. As H2 guy I would also reject patch like this.
> >> >
> >> > Sergi
> >> >
> >> > 2017-04-12 13:10 GMT+03:00 Alexander Paschenko <
> >> > alexander.a.pasche...@gmail.com >:
> >> >
> >> > > Sergi,
> >> > >
> >> > > Please have a closer look at what I've written in my first post. I
> >> don't
> >> > > see why we have to cling to H2 and its parsing modes all the time —
> >> after
> >> > > all, we're just talking string processing now, aren't we? (Yes,
> complex
> >> > and
> >> > > non trivial, but still.)
> >> > >
> >> > > What's wrong with idea of patching H2 to allow custom parsing? (With
> >> the
> >> > > parsing itself living in Ignite code, obviously, not in H2.).
> >> > >
> >> > > What I propose is just to make H2's Parser class extendable and
> make H2
> >> > > aware of its descendants via config params. And that's all with
> respect
> >> > to
> >> > > H2, nothing more.
> >> > >
> >> > > After that, on Ignite side we do all we want with our parser based
> on
> >> > > theirs. It resembles story with custom types — first we make H2
> >> > extendable
> >> > > in the way we need, then we introduce exact features we need on
> Ignite
> >> > > side.
> >> > >
> >> > > — Alex
> >> > >
> >> > > среда, 12 апреля 2017 г. пользователь Sergi Vladykin написал:
> >> > >
> >> > > > It definitely makes sense to add a separate mode for Ignite in H2.
> >> > Though
> >> > > > it is wrong to think that it will allow us to add any crazy
> syntax we
> >> > > want
> >> > > > (and it is actually a wrong idea imo), only the minor variations
> of
> >> the
> >> > > > existing syntax. But this must be enough.
> >> > > >
> >> > > > I believe we should end up with something like
> >> > > >
> >> > > > CREATE TABLE person
> >> > > > (
> >> > > >   id INT PRIMARY KEY,
> >> > > >   orgId INT AFFINITY KEY,
> >> > > >   name VARCHAR
> >> > > > )
> >> > > > WITH "cfg:my_config_template.xml"
> >> > > >
> >> > > > Sergi
> >> > > >
> >> > > >
> >> > > > 2017-04-12 7:54 GMT+03:00 Dmitriy Setrakyan <
> dsetrak...@apache.org
> >> > 
> >> > > > >:
> >> > > >
> >> > > > > Agree, the updated syntax looks better. One change though: KEY
> ->
> >> > > PRIMARY
> >> > > > > KEY.
> >> > > > >
> >> > > > > Sergi, what do you think?
> >> > > > >
> >> > > > > D.
> >> > > > >
> >> > > > > On Tue, Apr 11, 2017 at 9:50 PM, Pavel Tupitsyn <
> >> > ptupit...@apache.org 
> >> > > > >
> >> > > > > wrote:
> >> > > > >
> >> > > > > > I think "WITH" syntax is ugly and cumbersome.
> >> > > > > >
> >> > > > > > We should go with this one:
> >> > > > > > CREATE TABLE Person (id int AFFINITY KEY, uid uuid KEY,
> firstName
> >> > > > > > varchar, lastName varchar)
> >> > > > > >
> >> > > > > > All databases (i.e. [1], [2]) work this way, I see no reason
> to
> >> > > invent
> >> > > > > > something different and confuse the users.
> >> > > > > >
> >> > > > > > [1]
> >> > > > > > https://docs.microsoft.com/en-us/sql/t-sql/statements/create
> >> > > > > > -table-transact-sql#syntax-1
> >> > > > > > [2] https://www.postgresql.org/docs/9.1/static/sql-
> >> > createtable.html
> >> > > > > >
> >> > > > > > On Wed, Apr 

Re: Session expiration in Cassandra store

[Igor Rudyak]

Hi Val,

1) The genral idea is to have a session pool, cause closing and reopening
Cassandra session each time is rather expensive operation.

2) I can easily add session expiration timeout as a parameter for Cassandra
store. Will create a ticket for this.

3) It could be easily implemented ether, by closing and reopening session
every time or just keeping opened sessions forever, but both approaches are
bad. It's better to have a session pool and specify rather long session
expiration timeout.

Igor


On Apr 12, 2017 2:48 AM, "Valentin Kulichenko" <
valentin.kuliche...@gmail.com> wrote:

Hi Igor,

I recently faced an issue with Cassandra store closing idle connections
after some time. While investigating I found that this is caused by
SessionPool and its SessionMonitor thread which closes sessions that were
not acquired from the pool within 5 minutes.

I have several questions regarding this:

   - What is the general idea behind this?
   - Why the timeout is not configurable?
   - Is it possible to add an option to disable this thread completely?
   Will this have any drawbacks?

-Val

Re: question: How data are stored in IgniteCache?

[Vyacheslav Daradur]

In what cases BinaryObjecImpl is used?

2017-04-12 18:08 GMT+03:00 Denis Magda :

> Hi,
>
> A cache entry is always stored in a binary format (byte array) in a cache.
> Even when you transfer an entry from one node to another, as a result of
> cache.put(…), operation the entry will be serialized into the binary format
> and transferred over the wire.
>
> —
> Denis
>
> > On Apr 12, 2017, at 1:11 AM, Vyacheslav Daradur 
> wrote:
> >
> > Hello Igniters!
> >
> > I have one conceptual question:
> >
> > When we put an object in IgniteCache, how it is stored?
> >
> > As I understand, after marshalling we have an array of bytes,
> > 1) in a local node it is wrapped in BinaryObjectImpl and stored in memory
> > 2) it is sent to remote node as byte array where it will be wrapped in
> > BinaryObjectImpl and be stored in memory
> >
> > --
> > Best Regards, Vyacheslav
>
>


-- 
Best Regards, Vyacheslav

incorrect work of IgniteLogger

[ALEKSEY KUZNETSOV]

Igniters! Suppose we have log4j-test.xml as following:
...





















...

Why damn IgniteLogger doesn't write info logs from
TxOptimisticDeadlockDetectionTest class ?!?
-- 

*Best Regards,*

*Kuznetsov Aleksey*

Re: question: How data are stored in IgniteCache?

[Denis Magda]

Hi,

A cache entry is always stored in a binary format (byte array) in a cache. Even 
when you transfer an entry from one node to another, as a result of 
cache.put(…), operation the entry will be serialized into the binary format and 
transferred over the wire.

—
Denis

> On Apr 12, 2017, at 1:11 AM, Vyacheslav Daradur  wrote:
> 
> Hello Igniters!
> 
> I have one conceptual question:
> 
> When we put an object in IgniteCache, how it is stored?
> 
> As I understand, after marshalling we have an array of bytes,
> 1) in a local node it is wrapped in BinaryObjectImpl and stored in memory
> 2) it is sent to remote node as byte array where it will be wrapped in
> BinaryObjectImpl and be stored in memory
> 
> -- 
> Best Regards, Vyacheslav

[jira] [Created] (IGNITE-4953) Rework logic of concurrent schema changes

[Alexander Paschenko (JIRA)]

Alexander Paschenko created IGNITE-4953:
---

 Summary: Rework logic of concurrent schema changes
 Key: IGNITE-4953
 URL: https://issues.apache.org/jira/browse/IGNITE-4953
 Project: Ignite
  Issue Type: Bug
  Components: SQL
Affects Versions: 2.0
Reporter: Alexander Paschenko
Assignee: Alexander Paschenko
 Fix For: 2.0


H2's prepared statements store references to indexes that were present when the 
statement was parsed and initialized - this means that currently there's no way 
to prevent index usage if it goes down between the moment when the statement is 
created and actually executed. Have to come up with some new locking schema.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] ignite pull request #1781: Ignite 4950

[kdudkov]

GitHub user kdudkov opened a pull request:

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

Ignite 4950



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

$ git pull https://github.com/gridgain/apache-ignite ignite-4950

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

https://github.com/apache/ignite/pull/1781.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 #1781






---
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: SQL on PARTITIONED vs REPLICATED cache

[Andrey Mashenkov]

Yes, it's reasonable.

On Wed, Apr 12, 2017 at 3:23 PM, Sergi Vladykin 
wrote:

> Good point, but I'm not sure. The difference is that on client node you
> should not be able to enable isLocal, while isReplicatedOnly is perfectly
> valid. What do you think?
>
> Sergi
>
> 2017-04-12 15:18 GMT+03:00 Andrey Mashenkov :
>
> > Sergi,
> >
> > Got it.
> >
> > Does query execution way and results will be same for isReplicatedOnly
> flag
> > and for isLocal flag turned on?
> > If my understanding is correct, we will get same results and there is no
> > need to introduce a new flag.
> >
> >
> >
> > On Wed, Apr 12, 2017 at 2:54 PM, Sergi Vladykin <
> sergi.vlady...@gmail.com>
> > wrote:
> >
> > > Ok, let it be an exception. I'm just saying that the thing does not
> work
> > > now.
> > >
> > > Sergi
> > >
> > > 2017-04-12 14:50 GMT+03:00 Andrey Mashenkov <
> andrey.mashen...@gmail.com
> > >:
> > >
> > > > Sergi,
> > > >
> > > > I wounder how it is possible?
> > > >
> > > > Looks like it is impossible to run query on replicated cache, but
> > select
> > > > data from a
> > > > partitioned table. It will result with IlleagalStateException on
> stable
> > > > topology or
> > > > IgniteCacheException on unstable topology.
> > > > See ReduceQueryExecutor.stableDataNodes() and
> > > > replicatedUnstableDataNodes()
> > > >  methods.
> > > >
> > > > BTW, IlleagalStateException with no message is confusing.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Wed, Apr 12, 2017 at 2:36 PM, Sergi Vladykin <
> > > sergi.vlady...@gmail.com>
> > > > wrote:
> > > >
> > > > > Andrey,
> > > > >
> > > > > Because if you run query on replicated cache, but select data from
> a
> > > > > partitioned table, you will get only a part of the result.
> > > > >
> > > > > Igor,
> > > > >
> > > > > You are mostly right, but
> > > > >
> > > > > 1. Performance characteristics may change.
> > > > > 2. Ignite SQL processing pipeline may not support all the stuff in
> H2
> > > SQL
> > > > > and fail in some case where it worked previously.
> > > > >
> > > > > Because of this the change may affect existing applications and I
> > want
> > > to
> > > > > have it in 2.0 to make it legal.
> > > > >
> > > > > Sergi
> > > > >
> > > > > 2017-04-12 14:10 GMT+03:00 Igor Sapego :
> > > > >
> > > > > > Also, is it really a breaking change if the results are wrong?
> > > > > > To me it looks more like a bugfix, i.e. you can't break something
> > > > > > that does not work properly.
> > > > > >
> > > > > > Best Regards,
> > > > > > Igor
> > > > > >
> > > > > > On Wed, Apr 12, 2017 at 2:04 PM, Andrey Mashenkov <
> > > > > > andrey.mashen...@gmail.com> wrote:
> > > > > >
> > > > > > > Sergi,
> > > > > > >
> > > > > > > How can query to replicated cache leads to to wrong results?
> > > > > > > Is it due to we can read backup entries?
> > > > > > >
> > > > > > > On Wed, Apr 12, 2017 at 12:31 PM, Sergi Vladykin <
> > > > > > sergi.vlady...@gmail.com
> > > > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Guys,
> > > > > > > >
> > > > > > > > I want to introduce another breaking change for 2.0.
> > > > > > > >
> > > > > > > > Currently SQL is being processed differently when we call
> > method
> > > > > > `query`
> > > > > > > on
> > > > > > > > partitioned cache and on replicated: on replicated cache we
> do
> > > not
> > > > do
> > > > > > any
> > > > > > > > extra processing and execute the query as is on current node.
> > > > > > > >
> > > > > > > > This behavior historically existed for performance reasons.
> But
> > > it
> > > > is
> > > > > > not
> > > > > > > > obvious and leads to wrong query results. This issue becomes
> > even
> > > > > more
> > > > > > > > creepy with JDBC and ODBC drivers.
> > > > > > > >
> > > > > > > > In 2.0 I want to execute all the SQL queries the same way
> > through
> > > > the
> > > > > > > whole
> > > > > > > > processing pipeline to guaranty the correct result
> > irrespectively
> > > > to
> > > > > > the
> > > > > > > > cache that was the query originator.
> > > > > > > >
> > > > > > > > To be able to have the old behavior (skip all the
> preprocessing
> > > and
> > > > > run
> > > > > > > > query on current node) add a flag isReplicatedOnly() on
> > SqlQuery
> > > > and
> > > > > > > > SqlFieldsQuery. It will be disabled by default and if one
> knows
> > > > that
> > > > > > the
> > > > > > > > only replicated tables participate in a query, then he can
> > enable
> > > > it
> > > > > > for
> > > > > > > > better performance.
> > > > > > > >
> > > > > > > > Sergi
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Best regards,
> > > > > > > Andrey V. Mashenkov
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Best regards,
> > > > Andrey V. Mashenkov
> > > >
> > >
> >
> >
> >
> > --
> > Best regards,
> > Andrey V. Mashenkov
> >
>



-- 
Best regards,
Andrey V. Mashenkov

Re: Ignite-4795 - ready for review (Inherit TransactionException and update Javadoc)

[Andrey Gura]

Dmitry,

thanks a lot for your contribution. Changes are merged into master branch.

On Mon, Apr 10, 2017 at 7:07 PM, Andrey Gura  wrote:
> Thanks, Dmitry! I've reviewed your changes again and will merge it
> after TC results.
>
> On Mon, Apr 10, 2017 at 3:08 PM, Дмитрий Рябов  wrote:
>> Andrey, actual PR is 1630. PR 1631 was created by mistake and I closed it
>> immediately after creating (couse ticket must have only 1 PR, isn't it?).
>> So ticket has only one attached link to "GitHub Pull Request #1630".
>>
>> 2017-04-10 14:24 GMT+03:00 Andrey Gura :
>>
>>> Dmitry,
>>>
>>> this review is in progress. But I'm confused about PR number because
>>> in JIRA ticket we discussed PR 1631. What is actual PR number for
>>> latest changes?
>>>
>>> On Mon, Apr 10, 2017 at 11:38 AM, Дмитрий Рябов 
>>> wrote:
>>> > Hello, igniters. Please, review.
>>> >
>>> > PR: https://github.com/apache/ignite/pull/1630/files
>>> >
>>> > JIRA: https://issues.apache.org/jira/browse/IGNITE-4795
>>>

[GitHub] ignite pull request #1770: ignite-4795 All transactional methods of IgniteCa...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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: IgniteSemaphore and failoverSafe flag

[Vladisav Jelisavcic]

Hi Dmitry,

sure, I made a fix, take a look at the PR and the comments in the ticket.

Best regards,
Vladisav

On Tue, Apr 11, 2017 at 3:00 PM, Dmitry Karachentsev <
dkarachent...@gridgain.com> wrote:

> Hi Vladislav,
>
> Thanks for your contribution! But it seems doesn't fix related tickets, in
> particular [1].
> Could you please take a look?
>
> [1] https://issues.apache.org/jira/browse/IGNITE-4173
>
> Thanks!
>
> 06.04.2017 16:27, Vladisav Jelisavcic пишет:
>
> Hey Dmitry,
>
> sorry for the late reply, I'll try to bake a pr later during the day.
>
> Best regards,
> Vladisav
>
>
>
> On Tue, Apr 4, 2017 at 11:05 AM, Dmitry Karachentsev <
> dkarachent...@gridgain.com> wrote:
>
>> Hi Vladislav,
>>
>> I see you're developing [1] for a while, did you have any chance to fix
>> it? If no, is there any estimate?
>>
>> [1] https://issues.apache.org/jira/browse/IGNITE-1977
>>
>> Thanks!
>>
>> -Dmitry.
>>
>>
>>
>> 20.03.2017 10:28, Alexey Goncharuk пишет:
>>
>> I think re-creation should be handled by a user who will make sure that
>>> nobody else is currently executing the guarded logic before the
>>> re-creation. This is exactly the same semantics as with
>>> BrokenBarrierException for j.u.c.CyclicBarrier.
>>>
>>> 2017-03-17 2:39 GMT+03:00 Vladisav Jelisavcic :
>>>
>>> Hi everyone,

 I agree with Val, he's got a point; recreating the lock doesn't seem
 possible
 (at least not the with the transactional cache lock/semaphore we have).
 Is this re-create behavior really needed?

 Best regards,
 Vladisav



 On Thu, Mar 16, 2017 at 8:34 PM, Valentin Kulichenko <
 valentin.kuliche...@gmail.com> wrote:

 Guys,
>
> How does recreation of the lock helps? My understanding is that
> scenario
>
 is

> the following:
>
> 1. Client A creates and acquires a lock, and then starts to execute
>
 guarded

> logic.
> 2. Client B tries to acquire the same lock and parks to wait.
> 3. Before client A unlocks, all affinity nodes for the lock fail, lock
> disappears from the cache.
> 4. Client B fails with exception, recreates the lock, acquires it, and
> starts to execute guarded logic concurrently with client A.
>
> In my view this is wrong anyway, regardless of whether this happens
> silently or with an exception handled in user's code. Because this code
> doesn't have any way to know if client A still holds the lock or not.
>
> Am I missing something?
>
> -Val
>
> On Tue, Mar 14, 2017 at 10:14 AM, Dmitriy Setrakyan <
>
 dsetrak...@apache.org

> wrote:
>
> On Tue, Mar 14, 2017 at 12:46 AM, Alexey Goncharuk <
>> alexey.goncha...@gmail.com> wrote:
>>
>> Which user operation would result in exception? To my knowledge,

>>> user

> may
>>
>>> already be holding the lock and not invoking any Ignite APIs, no?

 Yes, this is exactly my point.
>>>
>>> Imagine that a node already holds a lock and another node is waiting
>>>
>> for
>
>> the lock. If all partition nodes leave the grid and the lock is
>>>
>> re-created,
>>
>>> this second node will immediately acquire the lock and we will have
>>>
>> two

> lock owners. I think in this case this second node (blocked on
>>>
>> lock())

> should get an exception saying that the lock was lost (which is, by
>>>
>> the

> way, the current behavior), and the first node should get an
>>>
>> exception

> on
>
>> unlock.
>>>
>>> Makes sense.
>>
>>
>>
>
>

Re: CREATE TABLE SQL command syntax

[Alexander Paschenko]

Sergi,

First, it would be as little as overriding the part responsible for
CREATE TABLE - there's no need to touch anything else as luckily H2
parser is internally structured well enough.

Second, although it is not all-around perfect, I am most confident
that this is far better than dragging into H2 bunch of stuff that they
don't really need just because we need it there or can smug it there.

I think I'll just spend some time in the weekend and come up with a
prototype as otherwise this talk seems to be just a chit-chat.

- Alex

2017-04-12 14:38 GMT+03:00 Sergi Vladykin :
> So basically in inherited class you are going co copy/paste base class
> methods and tweak them? I don't like this approach.
>
> Sergi
>
> 2017-04-12 14:07 GMT+03:00 Alexander Paschenko <
> alexander.a.pasche...@gmail.com>:
>
>> Sergi,
>>
>> As I've written in my previous post, it would be just inheriting Parser on
>> Ignite side and plugging its instance in SINGLE place. Just making H2's
>> Parser internal methods protected instead of private would let us do the
>> trick.
>>
>> — Alex
>>
>> среда, 12 апреля 2017 г. пользователь Sergi Vladykin написал:
>>
>> > I don't see how you make H2 Parser extendable, you will have to add
>> plugin
>> > call to every *potentially* extendable place in it. In general this does
>> > not work. As H2 guy I would also reject patch like this.
>> >
>> > Sergi
>> >
>> > 2017-04-12 13:10 GMT+03:00 Alexander Paschenko <
>> > alexander.a.pasche...@gmail.com >:
>> >
>> > > Sergi,
>> > >
>> > > Please have a closer look at what I've written in my first post. I
>> don't
>> > > see why we have to cling to H2 and its parsing modes all the time —
>> after
>> > > all, we're just talking string processing now, aren't we? (Yes, complex
>> > and
>> > > non trivial, but still.)
>> > >
>> > > What's wrong with idea of patching H2 to allow custom parsing? (With
>> the
>> > > parsing itself living in Ignite code, obviously, not in H2.).
>> > >
>> > > What I propose is just to make H2's Parser class extendable and make H2
>> > > aware of its descendants via config params. And that's all with respect
>> > to
>> > > H2, nothing more.
>> > >
>> > > After that, on Ignite side we do all we want with our parser based on
>> > > theirs. It resembles story with custom types — first we make H2
>> > extendable
>> > > in the way we need, then we introduce exact features we need on Ignite
>> > > side.
>> > >
>> > > — Alex
>> > >
>> > > среда, 12 апреля 2017 г. пользователь Sergi Vladykin написал:
>> > >
>> > > > It definitely makes sense to add a separate mode for Ignite in H2.
>> > Though
>> > > > it is wrong to think that it will allow us to add any crazy syntax we
>> > > want
>> > > > (and it is actually a wrong idea imo), only the minor variations of
>> the
>> > > > existing syntax. But this must be enough.
>> > > >
>> > > > I believe we should end up with something like
>> > > >
>> > > > CREATE TABLE person
>> > > > (
>> > > >   id INT PRIMARY KEY,
>> > > >   orgId INT AFFINITY KEY,
>> > > >   name VARCHAR
>> > > > )
>> > > > WITH "cfg:my_config_template.xml"
>> > > >
>> > > > Sergi
>> > > >
>> > > >
>> > > > 2017-04-12 7:54 GMT+03:00 Dmitriy Setrakyan > > 
>> > > > >:
>> > > >
>> > > > > Agree, the updated syntax looks better. One change though: KEY ->
>> > > PRIMARY
>> > > > > KEY.
>> > > > >
>> > > > > Sergi, what do you think?
>> > > > >
>> > > > > D.
>> > > > >
>> > > > > On Tue, Apr 11, 2017 at 9:50 PM, Pavel Tupitsyn <
>> > ptupit...@apache.org 
>> > > > >
>> > > > > wrote:
>> > > > >
>> > > > > > I think "WITH" syntax is ugly and cumbersome.
>> > > > > >
>> > > > > > We should go with this one:
>> > > > > > CREATE TABLE Person (id int AFFINITY KEY, uid uuid KEY, firstName
>> > > > > > varchar, lastName varchar)
>> > > > > >
>> > > > > > All databases (i.e. [1], [2]) work this way, I see no reason to
>> > > invent
>> > > > > > something different and confuse the users.
>> > > > > >
>> > > > > > [1]
>> > > > > > https://docs.microsoft.com/en-us/sql/t-sql/statements/create
>> > > > > > -table-transact-sql#syntax-1
>> > > > > > [2] https://www.postgresql.org/docs/9.1/static/sql-
>> > createtable.html
>> > > > > >
>> > > > > > On Wed, Apr 12, 2017 at 6:12 AM, Alexander Paschenko <
>> > > > > > alexander.a.pasche...@gmail.com  >
>> > wrote:
>> > > > > >
>> > > > > > > Dmitry,
>> > > > > > >
>> > > > > > > For H2 it would be something like this - please note all those
>> > > > quotes,
>> > > > > > > commas and equality signs that would be mandatory:
>> > > > > > >
>> > > > > > > CREATE TABLE Person (id int, uid uuid, firstName varchar,
>> > lastName
>> > > > > > > varchar) WITH "keyFields=id,uuid","affinityKey=id"
>> > > > > > >
>> > > > > > > With suggested approach, it would be something like
>> > > > > > >
>> > > > > > > CREATE TABLE Person (id int AFFINITY KEY, uid uuid KEY,
>> 

[GitHub] ignite pull request #1780: IGNITE-4173

[vladisav]

GitHub user vladisav opened a pull request:

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

IGNITE-4173 



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

$ git pull https://github.com/vladisav/ignite ignite-4173

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

https://github.com/apache/ignite/pull/1780.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 #1780


commit 76e9098bc67bb4bf660ebc147be89b64a8256c8d
Author: vladisav 
Date:   2017-04-12T13:27:55Z

Fixes ignite-4173;




---
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-4952) Swapping-related Event Types must be deleted

[Sergey Chugunov (JIRA)]

Sergey Chugunov created IGNITE-4952:
---

 Summary: Swapping-related Event Types must be deleted
 Key: IGNITE-4952
 URL: https://issues.apache.org/jira/browse/IGNITE-4952
 Project: Ignite
  Issue Type: Task
Reporter: Sergey Chugunov
Assignee: Sergey Chugunov


h2. Notes
As swap storage was removed in 
[IGNITE-3477|https://issues.apache.org/jira/browse/IGNITE-3477] there is no 
need to keep swap-related Event Types in ignite codebase.

h2. Acceptance Criteria
# Swap-related Event Types are removed from EventType enum.
# All tests verifying swap functionality are removed from tests set.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-4951) Discontinue AffintiyKeyMapper interface

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-4951:
---

 Summary: Discontinue AffintiyKeyMapper interface
 Key: IGNITE-4951
 URL: https://issues.apache.org/jira/browse/IGNITE-4951
 Project: Ignite
  Issue Type: Task
  Components: cache
Affects Versions: 2.0
Reporter: Vladimir Ozerov
Assignee: Konstantin Dudkov






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-4950) Do not allow AffinityKeyMapped annotation on methods

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-4950:
---

 Summary: Do not allow AffinityKeyMapped annotation on methods
 Key: IGNITE-4950
 URL: https://issues.apache.org/jira/browse/IGNITE-4950
 Project: Ignite
  Issue Type: Task
  Components: cache
Reporter: Vladimir Ozerov
Assignee: Konstantin Dudkov
 Fix For: 2.0






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: build failure in the master branch

[Rishi Yagnik]

I build it last night it worked for me..I am using Jdk8-121, hope that helps ..

Take Care,
Rishi

> On Apr 12, 2017, at 5:37 AM, Vyacheslav Daradur  wrote:
> 
> Does anyone has the same problem?
> 
> 2017-04-12 12:30 GMT+03:00 Vyacheslav Daradur :
> 
>> Last commit [1] 12.04.2017 6:19:06
>> 
>> mvn -X clean package -DskipTests
>> 
>> result:
>> ***
>> [DEBUG] parsing done in 2ms.
>> JavaDoc error: 'Other Packages' section should not be present, all
>> packages shou
>> ld have corresponding documentation groups: C:\Users\SBT-Daradur-V\
>> Projects\igni
>> te\target\javadoc\core/overview-summary.html
>> [DEBUG] parsing started
>> [DEBUG] DomTree builder started.
>> [DEBUG] LagartoDom tree created in 4 ms.
>> [DEBUG] parsing done in 5ms.
>> [DEBUG] parsing started
>> [DEBUG] DomTree builder started.
>> [DEBUG] LagartoDom tree created in 4 ms.
>> [DEBUG] parsing done in 4ms.
>> [INFO] 
>> 
>> [INFO] Reactor Summary:
>> [INFO]
>> [INFO] ignite-apache-license-gen .. SUCCESS [
>> 1.473 s]
>> [INFO] ignite-tools ... SUCCESS [
>> 5.950 s]
>> [INFO] ignite-core  SUCCESS
>> [02:25 min]
>> [INFO] ignite-log4j ... SUCCESS [
>> 4.440 s]
>> [INFO] ignite-indexing  SUCCESS [
>> 12.198 s]
>> [INFO] ignite-urideploy ... SUCCESS [
>> 4.338 s]
>> [INFO] ignite-spring .. SUCCESS [
>> 5.500 s]
>> [INFO] ignite-hadoop .. SUCCESS [
>> 15.860 s]
>> [INFO] ignite-extdata-p2p . SUCCESS [
>> 4.629 s]
>> [INFO] ignite-extdata-uri-dep . SUCCESS [
>> 2.210 s]
>> [INFO] ignite-extdata-uri . SUCCESS [
>> 1.033 s]
>> [INFO] ignite-rest-http ... SUCCESS [
>> 4.003 s]
>> [INFO] ignite-clients . SUCCESS [
>> 2.153 s]
>> [INFO] ignite-spring-data . SUCCESS [
>> 3.284 s]
>> [INFO] ignite-web . SUCCESS [
>> 3.487 s]
>> [INFO] ignite-aop . SUCCESS [
>> 3.365 s]
>> [INFO] ignite-ssh . SUCCESS [
>> 3.135 s]
>> [INFO] ignite-jta . SUCCESS [
>> 3.762 s]
>> [INFO] ignite-aws . SUCCESS [
>> 3.550 s]
>> [INFO] ignite-log4j2 .. SUCCESS [
>> 3.074 s]
>> [INFO] ignite-slf4j ... SUCCESS [
>> 2.650 s]
>> [INFO] ignite-jcl . SUCCESS [
>> 2.515 s]
>> [INFO] ignite-codegen . SUCCESS [
>> 2.364 s]
>> [INFO] ignite-gce . SUCCESS [
>> 2.713 s]
>> [INFO] ignite-cloud ... SUCCESS [
>> 4.806 s]
>> [INFO] ignite-mesos ... SUCCESS [
>> 4.260 s]
>> [INFO] ignite-kafka ... SUCCESS [
>> 4.889 s]
>> [INFO] ignite-flume ... SUCCESS [
>> 3.584 s]
>> [INFO] ignite-yarn  SUCCESS [
>> 10.306 s]
>> [INFO] ignite-jms11 ... SUCCESS [
>> 3.234 s]
>> [INFO] ignite-twitter . SUCCESS [
>> 3.141 s]
>> [INFO] ignite-mqtt  SUCCESS [
>> 3.578 s]
>> [INFO] ignite-zookeeper ... SUCCESS [
>> 3.395 s]
>> [INFO] ignite-camel ... SUCCESS [
>> 3.579 s]
>> [INFO] ignite-storm ... SUCCESS [
>> 3.147 s]
>> [INFO] ignite-osgi-paxlogging . SUCCESS [
>> 0.728 s]
>> [INFO] ignite-osgi-karaf .. SUCCESS [
>> 0.381 s]
>> [INFO] ignite-osgi  SUCCESS [
>> 4.074 s]
>> [INFO] ignite-appserver-test .. SUCCESS [
>> 0.591 s]
>> [INFO] ignite-websphere-test .. SUCCESS [
>> 3.345 s]
>> [INFO] ignite-cassandra ... SUCCESS [
>> 0.355 s]
>> [INFO] ignite-cassandra-store . SUCCESS [
>> 10.290 s]
>> [INFO] ignite-cassandra-serializers ... SUCCESS [
>> 3.740 s]
>> [INFO] ignite-flink ... SUCCESS [
>> 3.553 s]
>> [INFO] ignite-kubernetes .. SUCCESS [
>> 2.646 s]
>> [INFO] ignite-zeromq .. SUCCESS [
>> 2.621 s]
>> [INFO] ignite-scalar 

Re: SQL on PARTITIONED vs REPLICATED cache

[Sergi Vladykin]

Good point, but I'm not sure. The difference is that on client node you
should not be able to enable isLocal, while isReplicatedOnly is perfectly
valid. What do you think?

Sergi

2017-04-12 15:18 GMT+03:00 Andrey Mashenkov :

> Sergi,
>
> Got it.
>
> Does query execution way and results will be same for isReplicatedOnly flag
> and for isLocal flag turned on?
> If my understanding is correct, we will get same results and there is no
> need to introduce a new flag.
>
>
>
> On Wed, Apr 12, 2017 at 2:54 PM, Sergi Vladykin 
> wrote:
>
> > Ok, let it be an exception. I'm just saying that the thing does not work
> > now.
> >
> > Sergi
> >
> > 2017-04-12 14:50 GMT+03:00 Andrey Mashenkov  >:
> >
> > > Sergi,
> > >
> > > I wounder how it is possible?
> > >
> > > Looks like it is impossible to run query on replicated cache, but
> select
> > > data from a
> > > partitioned table. It will result with IlleagalStateException on stable
> > > topology or
> > > IgniteCacheException on unstable topology.
> > > See ReduceQueryExecutor.stableDataNodes() and
> > > replicatedUnstableDataNodes()
> > >  methods.
> > >
> > > BTW, IlleagalStateException with no message is confusing.
> > >
> > >
> > >
> > >
> > >
> > > On Wed, Apr 12, 2017 at 2:36 PM, Sergi Vladykin <
> > sergi.vlady...@gmail.com>
> > > wrote:
> > >
> > > > Andrey,
> > > >
> > > > Because if you run query on replicated cache, but select data from a
> > > > partitioned table, you will get only a part of the result.
> > > >
> > > > Igor,
> > > >
> > > > You are mostly right, but
> > > >
> > > > 1. Performance characteristics may change.
> > > > 2. Ignite SQL processing pipeline may not support all the stuff in H2
> > SQL
> > > > and fail in some case where it worked previously.
> > > >
> > > > Because of this the change may affect existing applications and I
> want
> > to
> > > > have it in 2.0 to make it legal.
> > > >
> > > > Sergi
> > > >
> > > > 2017-04-12 14:10 GMT+03:00 Igor Sapego :
> > > >
> > > > > Also, is it really a breaking change if the results are wrong?
> > > > > To me it looks more like a bugfix, i.e. you can't break something
> > > > > that does not work properly.
> > > > >
> > > > > Best Regards,
> > > > > Igor
> > > > >
> > > > > On Wed, Apr 12, 2017 at 2:04 PM, Andrey Mashenkov <
> > > > > andrey.mashen...@gmail.com> wrote:
> > > > >
> > > > > > Sergi,
> > > > > >
> > > > > > How can query to replicated cache leads to to wrong results?
> > > > > > Is it due to we can read backup entries?
> > > > > >
> > > > > > On Wed, Apr 12, 2017 at 12:31 PM, Sergi Vladykin <
> > > > > sergi.vlady...@gmail.com
> > > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Guys,
> > > > > > >
> > > > > > > I want to introduce another breaking change for 2.0.
> > > > > > >
> > > > > > > Currently SQL is being processed differently when we call
> method
> > > > > `query`
> > > > > > on
> > > > > > > partitioned cache and on replicated: on replicated cache we do
> > not
> > > do
> > > > > any
> > > > > > > extra processing and execute the query as is on current node.
> > > > > > >
> > > > > > > This behavior historically existed for performance reasons. But
> > it
> > > is
> > > > > not
> > > > > > > obvious and leads to wrong query results. This issue becomes
> even
> > > > more
> > > > > > > creepy with JDBC and ODBC drivers.
> > > > > > >
> > > > > > > In 2.0 I want to execute all the SQL queries the same way
> through
> > > the
> > > > > > whole
> > > > > > > processing pipeline to guaranty the correct result
> irrespectively
> > > to
> > > > > the
> > > > > > > cache that was the query originator.
> > > > > > >
> > > > > > > To be able to have the old behavior (skip all the preprocessing
> > and
> > > > run
> > > > > > > query on current node) add a flag isReplicatedOnly() on
> SqlQuery
> > > and
> > > > > > > SqlFieldsQuery. It will be disabled by default and if one knows
> > > that
> > > > > the
> > > > > > > only replicated tables participate in a query, then he can
> enable
> > > it
> > > > > for
> > > > > > > better performance.
> > > > > > >
> > > > > > > Sergi
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Best regards,
> > > > > > Andrey V. Mashenkov
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Best regards,
> > > Andrey V. Mashenkov
> > >
> >
>
>
>
> --
> Best regards,
> Andrey V. Mashenkov
>

[GitHub] ignite pull request #1779: IGNITE-3018 Cache affinity calculation is slow wi...

[tledkov-gridgain]

GitHub user tledkov-gridgain opened a pull request:

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

IGNITE-3018  Cache affinity calculation is slow with large nodes number



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

$ git pull https://github.com/gridgain/apache-ignite ignite-3018

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

https://github.com/apache/ignite/pull/1779.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 #1779


commit ed35a9eb6f02771c5996209a1e19a4b0557309b6
Author: tledkov-gridgain 
Date:   2017-02-27T09:49:31Z

IGNITE-3018: RendezvousAffinityFunction performance tuning

commit 3a6d17c2250158b54e3573af23b9b1534c3c8e92
Author: tledkov-gridgain 
Date:   2017-02-27T10:57:36Z

IGNITE-3018: fix review issues

commit db5512b65ce273d955ecd1c2381ade84491895ad
Author: tledkov-gridgain 
Date:   2017-03-02T14:32:04Z

Merge branch 'ignite-2.0' into ignite-3018

commit 163c05b6cea25aec0ca3b4ae4552338ed683631f
Author: tledkov-gridgain 
Date:   2017-04-12T12:18:14Z

Merge branch '_master' into ignite-3018

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/cache/affinity/rendezvous/RendezvousAffinityFunction.java

commit 3695d960597a5fdbebf43bf9a3bb57f85f4f394b
Author: tledkov-gridgain 
Date:   2017-04-12T12:18:57Z

IGNITE-3018: special assignment calculation for replicated cache

commit 9dfed00ba8be7676dc427f329fb9f557f71d4d21
Author: tledkov-gridgain 
Date:   2017-04-12T12:21:37Z

IGNITE-3018: exchange fix




---
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: SQL on PARTITIONED vs REPLICATED cache

[Andrey Mashenkov]

Sergi,

Got it.

Does query execution way and results will be same for isReplicatedOnly flag
and for isLocal flag turned on?
If my understanding is correct, we will get same results and there is no
need to introduce a new flag.



On Wed, Apr 12, 2017 at 2:54 PM, Sergi Vladykin 
wrote:

> Ok, let it be an exception. I'm just saying that the thing does not work
> now.
>
> Sergi
>
> 2017-04-12 14:50 GMT+03:00 Andrey Mashenkov :
>
> > Sergi,
> >
> > I wounder how it is possible?
> >
> > Looks like it is impossible to run query on replicated cache, but select
> > data from a
> > partitioned table. It will result with IlleagalStateException on stable
> > topology or
> > IgniteCacheException on unstable topology.
> > See ReduceQueryExecutor.stableDataNodes() and
> > replicatedUnstableDataNodes()
> >  methods.
> >
> > BTW, IlleagalStateException with no message is confusing.
> >
> >
> >
> >
> >
> > On Wed, Apr 12, 2017 at 2:36 PM, Sergi Vladykin <
> sergi.vlady...@gmail.com>
> > wrote:
> >
> > > Andrey,
> > >
> > > Because if you run query on replicated cache, but select data from a
> > > partitioned table, you will get only a part of the result.
> > >
> > > Igor,
> > >
> > > You are mostly right, but
> > >
> > > 1. Performance characteristics may change.
> > > 2. Ignite SQL processing pipeline may not support all the stuff in H2
> SQL
> > > and fail in some case where it worked previously.
> > >
> > > Because of this the change may affect existing applications and I want
> to
> > > have it in 2.0 to make it legal.
> > >
> > > Sergi
> > >
> > > 2017-04-12 14:10 GMT+03:00 Igor Sapego :
> > >
> > > > Also, is it really a breaking change if the results are wrong?
> > > > To me it looks more like a bugfix, i.e. you can't break something
> > > > that does not work properly.
> > > >
> > > > Best Regards,
> > > > Igor
> > > >
> > > > On Wed, Apr 12, 2017 at 2:04 PM, Andrey Mashenkov <
> > > > andrey.mashen...@gmail.com> wrote:
> > > >
> > > > > Sergi,
> > > > >
> > > > > How can query to replicated cache leads to to wrong results?
> > > > > Is it due to we can read backup entries?
> > > > >
> > > > > On Wed, Apr 12, 2017 at 12:31 PM, Sergi Vladykin <
> > > > sergi.vlady...@gmail.com
> > > > > >
> > > > > wrote:
> > > > >
> > > > > > Guys,
> > > > > >
> > > > > > I want to introduce another breaking change for 2.0.
> > > > > >
> > > > > > Currently SQL is being processed differently when we call method
> > > > `query`
> > > > > on
> > > > > > partitioned cache and on replicated: on replicated cache we do
> not
> > do
> > > > any
> > > > > > extra processing and execute the query as is on current node.
> > > > > >
> > > > > > This behavior historically existed for performance reasons. But
> it
> > is
> > > > not
> > > > > > obvious and leads to wrong query results. This issue becomes even
> > > more
> > > > > > creepy with JDBC and ODBC drivers.
> > > > > >
> > > > > > In 2.0 I want to execute all the SQL queries the same way through
> > the
> > > > > whole
> > > > > > processing pipeline to guaranty the correct result irrespectively
> > to
> > > > the
> > > > > > cache that was the query originator.
> > > > > >
> > > > > > To be able to have the old behavior (skip all the preprocessing
> and
> > > run
> > > > > > query on current node) add a flag isReplicatedOnly() on SqlQuery
> > and
> > > > > > SqlFieldsQuery. It will be disabled by default and if one knows
> > that
> > > > the
> > > > > > only replicated tables participate in a query, then he can enable
> > it
> > > > for
> > > > > > better performance.
> > > > > >
> > > > > > Sergi
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best regards,
> > > > > Andrey V. Mashenkov
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > Best regards,
> > Andrey V. Mashenkov
> >
>



-- 
Best regards,
Andrey V. Mashenkov

Re: [jira] [Commented] (IGNITE-4052) Add ability to set up users for MESOS

[Вадим Опольский]

Hello guys!

Nikolay, I looked at cassandra mesos integration, but cant find how to test
ability to configure mesos and user via system env properties. I will
continue to search in another projects which use Mesos.

Review please pull request - https://github.com/vadopolski/ignite/pull/2.
It contains new test and method for setting system environments.

Can you close issue https://issues.apache.org/jira/browse/IGNITE-4052 and
open new, about testing Mesos Integration.

Vadim Opolski

2017-04-03 12:13 GMT+03:00 Nikolay Tikhonov (JIRA) :

>
> [ https://issues.apache.org/jira/browse/IGNITE-4052?page=com.
> atlassian.jira.plugin.system.issuetabpanels:comment-tabpane
> l=15953167#comment-15953167 ]
>
> Nikolay Tikhonov commented on IGNITE-4052:
> --
>
> [~javaller],
> For example you can look at cassandra mesos integration
> https://github.com/mesosphere/dcos-cassandra-service/blob/5d
> 6d15e646f1df2fa10fa98d91993d3a6b4719c4/cassandra-commons/src
> /main/java/com/mesosphere/dcos/cassandra/common/config/ServiceConfig.java.
> List of application which use Mesos not secret and can be found on official
> mesos site http://mesos.apache.org/documentation/latest/frameworks. ;)
>
> I'm really don't understand how the libs can help you. Could you clarify
> it?
>
> > Add ability to set up users for MESOS
> > -
> >
> > Key: IGNITE-4052
> > URL: https://issues.apache.org/jira/browse/IGNITE-4052
> > Project: Ignite
> >  Issue Type: Improvement
> >  Components: general
> >Affects Versions: 1.7
> >Reporter: Nikolay Tikhonov
> >Assignee: Vadim Opolski
> >Priority: Trivial
> >
> > In current implementation Ignite Mesos Framework connects to MESOS
> cluster via current user. Need to add ability to configure this parameters
> via system env properties. Also need to add properties for mesos role.
> > See org/apache/ignite/mesos/IgniteFramework.java:537
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.15#6346)
>

Re: SQL on PARTITIONED vs REPLICATED cache

[Sergi Vladykin]

Ok, let it be an exception. I'm just saying that the thing does not work
now.

Sergi

2017-04-12 14:50 GMT+03:00 Andrey Mashenkov :

> Sergi,
>
> I wounder how it is possible?
>
> Looks like it is impossible to run query on replicated cache, but select
> data from a
> partitioned table. It will result with IlleagalStateException on stable
> topology or
> IgniteCacheException on unstable topology.
> See ReduceQueryExecutor.stableDataNodes() and
> replicatedUnstableDataNodes()
>  methods.
>
> BTW, IlleagalStateException with no message is confusing.
>
>
>
>
>
> On Wed, Apr 12, 2017 at 2:36 PM, Sergi Vladykin 
> wrote:
>
> > Andrey,
> >
> > Because if you run query on replicated cache, but select data from a
> > partitioned table, you will get only a part of the result.
> >
> > Igor,
> >
> > You are mostly right, but
> >
> > 1. Performance characteristics may change.
> > 2. Ignite SQL processing pipeline may not support all the stuff in H2 SQL
> > and fail in some case where it worked previously.
> >
> > Because of this the change may affect existing applications and I want to
> > have it in 2.0 to make it legal.
> >
> > Sergi
> >
> > 2017-04-12 14:10 GMT+03:00 Igor Sapego :
> >
> > > Also, is it really a breaking change if the results are wrong?
> > > To me it looks more like a bugfix, i.e. you can't break something
> > > that does not work properly.
> > >
> > > Best Regards,
> > > Igor
> > >
> > > On Wed, Apr 12, 2017 at 2:04 PM, Andrey Mashenkov <
> > > andrey.mashen...@gmail.com> wrote:
> > >
> > > > Sergi,
> > > >
> > > > How can query to replicated cache leads to to wrong results?
> > > > Is it due to we can read backup entries?
> > > >
> > > > On Wed, Apr 12, 2017 at 12:31 PM, Sergi Vladykin <
> > > sergi.vlady...@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > Guys,
> > > > >
> > > > > I want to introduce another breaking change for 2.0.
> > > > >
> > > > > Currently SQL is being processed differently when we call method
> > > `query`
> > > > on
> > > > > partitioned cache and on replicated: on replicated cache we do not
> do
> > > any
> > > > > extra processing and execute the query as is on current node.
> > > > >
> > > > > This behavior historically existed for performance reasons. But it
> is
> > > not
> > > > > obvious and leads to wrong query results. This issue becomes even
> > more
> > > > > creepy with JDBC and ODBC drivers.
> > > > >
> > > > > In 2.0 I want to execute all the SQL queries the same way through
> the
> > > > whole
> > > > > processing pipeline to guaranty the correct result irrespectively
> to
> > > the
> > > > > cache that was the query originator.
> > > > >
> > > > > To be able to have the old behavior (skip all the preprocessing and
> > run
> > > > > query on current node) add a flag isReplicatedOnly() on SqlQuery
> and
> > > > > SqlFieldsQuery. It will be disabled by default and if one knows
> that
> > > the
> > > > > only replicated tables participate in a query, then he can enable
> it
> > > for
> > > > > better performance.
> > > > >
> > > > > Sergi
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Best regards,
> > > > Andrey V. Mashenkov
> > > >
> > >
> >
>
>
>
> --
> Best regards,
> Andrey V. Mashenkov
>

Re: SQL on PARTITIONED vs REPLICATED cache

[Andrey Mashenkov]

Sergi,

I wounder how it is possible?

Looks like it is impossible to run query on replicated cache, but select
data from a
partitioned table. It will result with IlleagalStateException on stable
topology or
IgniteCacheException on unstable topology.
See ReduceQueryExecutor.stableDataNodes() and replicatedUnstableDataNodes()
 methods.

BTW, IlleagalStateException with no message is confusing.





On Wed, Apr 12, 2017 at 2:36 PM, Sergi Vladykin 
wrote:

> Andrey,
>
> Because if you run query on replicated cache, but select data from a
> partitioned table, you will get only a part of the result.
>
> Igor,
>
> You are mostly right, but
>
> 1. Performance characteristics may change.
> 2. Ignite SQL processing pipeline may not support all the stuff in H2 SQL
> and fail in some case where it worked previously.
>
> Because of this the change may affect existing applications and I want to
> have it in 2.0 to make it legal.
>
> Sergi
>
> 2017-04-12 14:10 GMT+03:00 Igor Sapego :
>
> > Also, is it really a breaking change if the results are wrong?
> > To me it looks more like a bugfix, i.e. you can't break something
> > that does not work properly.
> >
> > Best Regards,
> > Igor
> >
> > On Wed, Apr 12, 2017 at 2:04 PM, Andrey Mashenkov <
> > andrey.mashen...@gmail.com> wrote:
> >
> > > Sergi,
> > >
> > > How can query to replicated cache leads to to wrong results?
> > > Is it due to we can read backup entries?
> > >
> > > On Wed, Apr 12, 2017 at 12:31 PM, Sergi Vladykin <
> > sergi.vlady...@gmail.com
> > > >
> > > wrote:
> > >
> > > > Guys,
> > > >
> > > > I want to introduce another breaking change for 2.0.
> > > >
> > > > Currently SQL is being processed differently when we call method
> > `query`
> > > on
> > > > partitioned cache and on replicated: on replicated cache we do not do
> > any
> > > > extra processing and execute the query as is on current node.
> > > >
> > > > This behavior historically existed for performance reasons. But it is
> > not
> > > > obvious and leads to wrong query results. This issue becomes even
> more
> > > > creepy with JDBC and ODBC drivers.
> > > >
> > > > In 2.0 I want to execute all the SQL queries the same way through the
> > > whole
> > > > processing pipeline to guaranty the correct result irrespectively to
> > the
> > > > cache that was the query originator.
> > > >
> > > > To be able to have the old behavior (skip all the preprocessing and
> run
> > > > query on current node) add a flag isReplicatedOnly() on SqlQuery and
> > > > SqlFieldsQuery. It will be disabled by default and if one knows that
> > the
> > > > only replicated tables participate in a query, then he can enable it
> > for
> > > > better performance.
> > > >
> > > > Sergi
> > > >
> > >
> > >
> > >
> > > --
> > > Best regards,
> > > Andrey V. Mashenkov
> > >
> >
>



-- 
Best regards,
Andrey V. Mashenkov

Re: TouchedExpiryPolicy works incorrect in some cases IGNITE-4401

[ALEKSEY KUZNETSOV]

So what do u think about the issue ?

ср, 12 апр. 2017 г. в 10:42, ALEKSEY KUZNETSOV :

> I have already attached simlified version. Shall i simplify it more ?
>
> вт, 11 апр. 2017 г. в 19:28, Denis Magda :
>
> Can you attach the simplified version? Just want to avoid any side effects.
>
> —
> Denis
>
> > On Apr 11, 2017, at 9:14 AM, ALEKSEY KUZNETSOV 
> wrote:
> >
> > I took it from https://issues.apache.org/jira/browse/IGNITE-4401 <
> https://issues.apache.org/jira/browse/IGNITE-4401> and simplified . See
> in attached
> >
> >
> > вт, 11 апр. 2017 г. в 19:03, Denis Magda >:
> > Hello,
> >
> > Do you have sample code?
> >
> > —
> > Denis
> > > On Apr 11, 2017, at 2:45 AM, ALEKSEY KUZNETSOV <
> alkuznetsov...@gmail.com > wrote:
> > >
> > > Hi, igniters!
> > > While doing https://issues.apache.org/jira/browse/IGNITE-4401 <
> https://issues.apache.org/jira/browse/IGNITE-4401> ticket i came
> > > across the fact that cache querying returns null , while cache still
> has
> > > got entry.
> > > Cache query : SELECT nameProp FROM EDUProp WHERE EDUId = 1
> > > Cache get operation : ignite().cache("eduPropCache").get(new
> AffinityKey("1",
> > > "1")) non-null
> > > I cannot even imagine what could be wrong with it.
> > >
> > >
> > >
> > > --
> > >
> > > *Best Regards,*
> > >
> > > *Kuznetsov Aleksey*
> >
> > --
> > Best Regards,
> >
> > Kuznetsov Aleksey
> >
>
> --
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*
>
-- 

*Best Regards,*

*Kuznetsov Aleksey*

Re: CREATE TABLE SQL command syntax

[Sergi Vladykin]

So basically in inherited class you are going co copy/paste base class
methods and tweak them? I don't like this approach.

Sergi

2017-04-12 14:07 GMT+03:00 Alexander Paschenko <
alexander.a.pasche...@gmail.com>:

> Sergi,
>
> As I've written in my previous post, it would be just inheriting Parser on
> Ignite side and plugging its instance in SINGLE place. Just making H2's
> Parser internal methods protected instead of private would let us do the
> trick.
>
> — Alex
>
> среда, 12 апреля 2017 г. пользователь Sergi Vladykin написал:
>
> > I don't see how you make H2 Parser extendable, you will have to add
> plugin
> > call to every *potentially* extendable place in it. In general this does
> > not work. As H2 guy I would also reject patch like this.
> >
> > Sergi
> >
> > 2017-04-12 13:10 GMT+03:00 Alexander Paschenko <
> > alexander.a.pasche...@gmail.com >:
> >
> > > Sergi,
> > >
> > > Please have a closer look at what I've written in my first post. I
> don't
> > > see why we have to cling to H2 and its parsing modes all the time —
> after
> > > all, we're just talking string processing now, aren't we? (Yes, complex
> > and
> > > non trivial, but still.)
> > >
> > > What's wrong with idea of patching H2 to allow custom parsing? (With
> the
> > > parsing itself living in Ignite code, obviously, not in H2.).
> > >
> > > What I propose is just to make H2's Parser class extendable and make H2
> > > aware of its descendants via config params. And that's all with respect
> > to
> > > H2, nothing more.
> > >
> > > After that, on Ignite side we do all we want with our parser based on
> > > theirs. It resembles story with custom types — first we make H2
> > extendable
> > > in the way we need, then we introduce exact features we need on Ignite
> > > side.
> > >
> > > — Alex
> > >
> > > среда, 12 апреля 2017 г. пользователь Sergi Vladykin написал:
> > >
> > > > It definitely makes sense to add a separate mode for Ignite in H2.
> > Though
> > > > it is wrong to think that it will allow us to add any crazy syntax we
> > > want
> > > > (and it is actually a wrong idea imo), only the minor variations of
> the
> > > > existing syntax. But this must be enough.
> > > >
> > > > I believe we should end up with something like
> > > >
> > > > CREATE TABLE person
> > > > (
> > > >   id INT PRIMARY KEY,
> > > >   orgId INT AFFINITY KEY,
> > > >   name VARCHAR
> > > > )
> > > > WITH "cfg:my_config_template.xml"
> > > >
> > > > Sergi
> > > >
> > > >
> > > > 2017-04-12 7:54 GMT+03:00 Dmitriy Setrakyan  > 
> > > > >:
> > > >
> > > > > Agree, the updated syntax looks better. One change though: KEY ->
> > > PRIMARY
> > > > > KEY.
> > > > >
> > > > > Sergi, what do you think?
> > > > >
> > > > > D.
> > > > >
> > > > > On Tue, Apr 11, 2017 at 9:50 PM, Pavel Tupitsyn <
> > ptupit...@apache.org 
> > > > >
> > > > > wrote:
> > > > >
> > > > > > I think "WITH" syntax is ugly and cumbersome.
> > > > > >
> > > > > > We should go with this one:
> > > > > > CREATE TABLE Person (id int AFFINITY KEY, uid uuid KEY, firstName
> > > > > > varchar, lastName varchar)
> > > > > >
> > > > > > All databases (i.e. [1], [2]) work this way, I see no reason to
> > > invent
> > > > > > something different and confuse the users.
> > > > > >
> > > > > > [1]
> > > > > > https://docs.microsoft.com/en-us/sql/t-sql/statements/create
> > > > > > -table-transact-sql#syntax-1
> > > > > > [2] https://www.postgresql.org/docs/9.1/static/sql-
> > createtable.html
> > > > > >
> > > > > > On Wed, Apr 12, 2017 at 6:12 AM, Alexander Paschenko <
> > > > > > alexander.a.pasche...@gmail.com  >
> > wrote:
> > > > > >
> > > > > > > Dmitry,
> > > > > > >
> > > > > > > For H2 it would be something like this - please note all those
> > > > quotes,
> > > > > > > commas and equality signs that would be mandatory:
> > > > > > >
> > > > > > > CREATE TABLE Person (id int, uid uuid, firstName varchar,
> > lastName
> > > > > > > varchar) WITH "keyFields=id,uuid","affinityKey=id"
> > > > > > >
> > > > > > > With suggested approach, it would be something like
> > > > > > >
> > > > > > > CREATE TABLE Person (id int AFFINITY KEY, uid uuid KEY,
> firstName
> > > > > > > varchar, lastName varchar)
> > > > > > >
> > > > > > > While this may not look like a drastic improvement in this
> > > particular
> > > > > > > case, we someday most likely will want either an all-custom
> > CREATE
> > > > > > > CACHE command, or a whole bunch of new options for CREATE
> TABLE,
> > if
> > > > we
> > > > > > > decide not to go with CREATE CACHE - I personally think that
> > stuff
> > > > > > > like
> > > > > > >
> > > > > > > CREATE TABLE ... WITH
> > > > > > > "keyFields=id,uuid","affinityKey=id","cacheType=
> > > > > partitioned","atomicity=
> > > > > > > atomic","partitions=3"
> > > > > > >
> > > > > > > which will arise if we continue to try to stuff everything into
> > > WITH
> > > > > > 

Re: SQL on PARTITIONED vs REPLICATED cache

[Sergi Vladykin]

Andrey,

Because if you run query on replicated cache, but select data from a
partitioned table, you will get only a part of the result.

Igor,

You are mostly right, but

1. Performance characteristics may change.
2. Ignite SQL processing pipeline may not support all the stuff in H2 SQL
and fail in some case where it worked previously.

Because of this the change may affect existing applications and I want to
have it in 2.0 to make it legal.

Sergi

2017-04-12 14:10 GMT+03:00 Igor Sapego :

> Also, is it really a breaking change if the results are wrong?
> To me it looks more like a bugfix, i.e. you can't break something
> that does not work properly.
>
> Best Regards,
> Igor
>
> On Wed, Apr 12, 2017 at 2:04 PM, Andrey Mashenkov <
> andrey.mashen...@gmail.com> wrote:
>
> > Sergi,
> >
> > How can query to replicated cache leads to to wrong results?
> > Is it due to we can read backup entries?
> >
> > On Wed, Apr 12, 2017 at 12:31 PM, Sergi Vladykin <
> sergi.vlady...@gmail.com
> > >
> > wrote:
> >
> > > Guys,
> > >
> > > I want to introduce another breaking change for 2.0.
> > >
> > > Currently SQL is being processed differently when we call method
> `query`
> > on
> > > partitioned cache and on replicated: on replicated cache we do not do
> any
> > > extra processing and execute the query as is on current node.
> > >
> > > This behavior historically existed for performance reasons. But it is
> not
> > > obvious and leads to wrong query results. This issue becomes even more
> > > creepy with JDBC and ODBC drivers.
> > >
> > > In 2.0 I want to execute all the SQL queries the same way through the
> > whole
> > > processing pipeline to guaranty the correct result irrespectively to
> the
> > > cache that was the query originator.
> > >
> > > To be able to have the old behavior (skip all the preprocessing and run
> > > query on current node) add a flag isReplicatedOnly() on SqlQuery and
> > > SqlFieldsQuery. It will be disabled by default and if one knows that
> the
> > > only replicated tables participate in a query, then he can enable it
> for
> > > better performance.
> > >
> > > Sergi
> > >
> >
> >
> >
> > --
> > Best regards,
> > Andrey V. Mashenkov
> >
>

Re: SQL on PARTITIONED vs REPLICATED cache

[Igor Sapego]

Also, is it really a breaking change if the results are wrong?
To me it looks more like a bugfix, i.e. you can't break something
that does not work properly.

Best Regards,
Igor

On Wed, Apr 12, 2017 at 2:04 PM, Andrey Mashenkov <
andrey.mashen...@gmail.com> wrote:

> Sergi,
>
> How can query to replicated cache leads to to wrong results?
> Is it due to we can read backup entries?
>
> On Wed, Apr 12, 2017 at 12:31 PM, Sergi Vladykin  >
> wrote:
>
> > Guys,
> >
> > I want to introduce another breaking change for 2.0.
> >
> > Currently SQL is being processed differently when we call method `query`
> on
> > partitioned cache and on replicated: on replicated cache we do not do any
> > extra processing and execute the query as is on current node.
> >
> > This behavior historically existed for performance reasons. But it is not
> > obvious and leads to wrong query results. This issue becomes even more
> > creepy with JDBC and ODBC drivers.
> >
> > In 2.0 I want to execute all the SQL queries the same way through the
> whole
> > processing pipeline to guaranty the correct result irrespectively to the
> > cache that was the query originator.
> >
> > To be able to have the old behavior (skip all the preprocessing and run
> > query on current node) add a flag isReplicatedOnly() on SqlQuery and
> > SqlFieldsQuery. It will be disabled by default and if one knows that the
> > only replicated tables participate in a query, then he can enable it for
> > better performance.
> >
> > Sergi
> >
>
>
>
> --
> Best regards,
> Andrey V. Mashenkov
>

Re: CREATE TABLE SQL command syntax

[Alexander Paschenko]

Sergi,

As I've written in my previous post, it would be just inheriting Parser on
Ignite side and plugging its instance in SINGLE place. Just making H2's
Parser internal methods protected instead of private would let us do the
trick.

— Alex

среда, 12 апреля 2017 г. пользователь Sergi Vladykin написал:

> I don't see how you make H2 Parser extendable, you will have to add plugin
> call to every *potentially* extendable place in it. In general this does
> not work. As H2 guy I would also reject patch like this.
>
> Sergi
>
> 2017-04-12 13:10 GMT+03:00 Alexander Paschenko <
> alexander.a.pasche...@gmail.com >:
>
> > Sergi,
> >
> > Please have a closer look at what I've written in my first post. I don't
> > see why we have to cling to H2 and its parsing modes all the time — after
> > all, we're just talking string processing now, aren't we? (Yes, complex
> and
> > non trivial, but still.)
> >
> > What's wrong with idea of patching H2 to allow custom parsing? (With the
> > parsing itself living in Ignite code, obviously, not in H2.).
> >
> > What I propose is just to make H2's Parser class extendable and make H2
> > aware of its descendants via config params. And that's all with respect
> to
> > H2, nothing more.
> >
> > After that, on Ignite side we do all we want with our parser based on
> > theirs. It resembles story with custom types — first we make H2
> extendable
> > in the way we need, then we introduce exact features we need on Ignite
> > side.
> >
> > — Alex
> >
> > среда, 12 апреля 2017 г. пользователь Sergi Vladykin написал:
> >
> > > It definitely makes sense to add a separate mode for Ignite in H2.
> Though
> > > it is wrong to think that it will allow us to add any crazy syntax we
> > want
> > > (and it is actually a wrong idea imo), only the minor variations of the
> > > existing syntax. But this must be enough.
> > >
> > > I believe we should end up with something like
> > >
> > > CREATE TABLE person
> > > (
> > >   id INT PRIMARY KEY,
> > >   orgId INT AFFINITY KEY,
> > >   name VARCHAR
> > > )
> > > WITH "cfg:my_config_template.xml"
> > >
> > > Sergi
> > >
> > >
> > > 2017-04-12 7:54 GMT+03:00 Dmitriy Setrakyan  
> > > >:
> > >
> > > > Agree, the updated syntax looks better. One change though: KEY ->
> > PRIMARY
> > > > KEY.
> > > >
> > > > Sergi, what do you think?
> > > >
> > > > D.
> > > >
> > > > On Tue, Apr 11, 2017 at 9:50 PM, Pavel Tupitsyn <
> ptupit...@apache.org 
> > > >
> > > > wrote:
> > > >
> > > > > I think "WITH" syntax is ugly and cumbersome.
> > > > >
> > > > > We should go with this one:
> > > > > CREATE TABLE Person (id int AFFINITY KEY, uid uuid KEY, firstName
> > > > > varchar, lastName varchar)
> > > > >
> > > > > All databases (i.e. [1], [2]) work this way, I see no reason to
> > invent
> > > > > something different and confuse the users.
> > > > >
> > > > > [1]
> > > > > https://docs.microsoft.com/en-us/sql/t-sql/statements/create
> > > > > -table-transact-sql#syntax-1
> > > > > [2] https://www.postgresql.org/docs/9.1/static/sql-
> createtable.html
> > > > >
> > > > > On Wed, Apr 12, 2017 at 6:12 AM, Alexander Paschenko <
> > > > > alexander.a.pasche...@gmail.com  >
> wrote:
> > > > >
> > > > > > Dmitry,
> > > > > >
> > > > > > For H2 it would be something like this - please note all those
> > > quotes,
> > > > > > commas and equality signs that would be mandatory:
> > > > > >
> > > > > > CREATE TABLE Person (id int, uid uuid, firstName varchar,
> lastName
> > > > > > varchar) WITH "keyFields=id,uuid","affinityKey=id"
> > > > > >
> > > > > > With suggested approach, it would be something like
> > > > > >
> > > > > > CREATE TABLE Person (id int AFFINITY KEY, uid uuid KEY, firstName
> > > > > > varchar, lastName varchar)
> > > > > >
> > > > > > While this may not look like a drastic improvement in this
> > particular
> > > > > > case, we someday most likely will want either an all-custom
> CREATE
> > > > > > CACHE command, or a whole bunch of new options for CREATE TABLE,
> if
> > > we
> > > > > > decide not to go with CREATE CACHE - I personally think that
> stuff
> > > > > > like
> > > > > >
> > > > > > CREATE TABLE ... WITH
> > > > > > "keyFields=id,uuid","affinityKey=id","cacheType=
> > > > partitioned","atomicity=
> > > > > > atomic","partitions=3"
> > > > > >
> > > > > > which will arise if we continue to try to stuff everything into
> > WITH
> > > > > > will just bring more ugliness with time, and that's not to
> mention
> > > > > > that new CREATE CACHE syntax will be impossible or relatively
> hard
> > to
> > > > > > introduce as we will have to approve it with H2 folks, and that's
> > how
> > > > > > it will be with any new param or command that we want.
> > > > > >
> > > > > > Allowing to plug custom parser into H2 (as we do now with table
> > > > > > engine) will let us introduce any syntax we want and focus on
> > > > > > usability and 

Re: SQL on PARTITIONED vs REPLICATED cache

[Andrey Mashenkov]

Sergi,

How can query to replicated cache leads to to wrong results?
Is it due to we can read backup entries?

On Wed, Apr 12, 2017 at 12:31 PM, Sergi Vladykin 
wrote:

> Guys,
>
> I want to introduce another breaking change for 2.0.
>
> Currently SQL is being processed differently when we call method `query` on
> partitioned cache and on replicated: on replicated cache we do not do any
> extra processing and execute the query as is on current node.
>
> This behavior historically existed for performance reasons. But it is not
> obvious and leads to wrong query results. This issue becomes even more
> creepy with JDBC and ODBC drivers.
>
> In 2.0 I want to execute all the SQL queries the same way through the whole
> processing pipeline to guaranty the correct result irrespectively to the
> cache that was the query originator.
>
> To be able to have the old behavior (skip all the preprocessing and run
> query on current node) add a flag isReplicatedOnly() on SqlQuery and
> SqlFieldsQuery. It will be disabled by default and if one knows that the
> only replicated tables participate in a query, then he can enable it for
> better performance.
>
> Sergi
>



-- 
Best regards,
Andrey V. Mashenkov

[GitHub] ignite pull request #1778: client reconnect fix

[sergey-chugunov-1985]

GitHub user sergey-chugunov-1985 opened a pull request:

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

client reconnect fix



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

$ git pull https://github.com/gridgain/apache-ignite 
ignite-3477-master-client-reconn-fix

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

https://github.com/apache/ignite/pull/1778.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 #1778


commit 5cded42e8a45cd799122061499e0c95b00803504
Author: Ilya Lantukh 
Date:   2017-04-12T09:43:49Z

ignite-3477 : Fixed possible endless iteration over queue with evicted 
patitions.

commit 48b9aa3e36767697b1f7bcf7e32250f45d5e31fa
Author: Sergey Chugunov 
Date:   2017-04-12T10:41:09Z

ClientReconnectMessage id shouldn't be saved for lastMsgId on client side




---
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: build failure in the master branch

[Vyacheslav Daradur]

Does anyone has the same problem?

2017-04-12 12:30 GMT+03:00 Vyacheslav Daradur :

> Last commit [1] 12.04.2017 6:19:06
>
> mvn -X clean package -DskipTests
>
> result:
> ***
> [DEBUG] parsing done in 2ms.
> JavaDoc error: 'Other Packages' section should not be present, all
> packages shou
> ld have corresponding documentation groups: C:\Users\SBT-Daradur-V\
> Projects\igni
> te\target\javadoc\core/overview-summary.html
> [DEBUG] parsing started
> [DEBUG] DomTree builder started.
> [DEBUG] LagartoDom tree created in 4 ms.
> [DEBUG] parsing done in 5ms.
> [DEBUG] parsing started
> [DEBUG] DomTree builder started.
> [DEBUG] LagartoDom tree created in 4 ms.
> [DEBUG] parsing done in 4ms.
> [INFO] 
> 
> [INFO] Reactor Summary:
> [INFO]
> [INFO] ignite-apache-license-gen .. SUCCESS [
>  1.473 s]
> [INFO] ignite-tools ... SUCCESS [
>  5.950 s]
> [INFO] ignite-core  SUCCESS
> [02:25 min]
> [INFO] ignite-log4j ... SUCCESS [
>  4.440 s]
> [INFO] ignite-indexing  SUCCESS [
> 12.198 s]
> [INFO] ignite-urideploy ... SUCCESS [
>  4.338 s]
> [INFO] ignite-spring .. SUCCESS [
>  5.500 s]
> [INFO] ignite-hadoop .. SUCCESS [
> 15.860 s]
> [INFO] ignite-extdata-p2p . SUCCESS [
>  4.629 s]
> [INFO] ignite-extdata-uri-dep . SUCCESS [
>  2.210 s]
> [INFO] ignite-extdata-uri . SUCCESS [
>  1.033 s]
> [INFO] ignite-rest-http ... SUCCESS [
>  4.003 s]
> [INFO] ignite-clients . SUCCESS [
>  2.153 s]
> [INFO] ignite-spring-data . SUCCESS [
>  3.284 s]
> [INFO] ignite-web . SUCCESS [
>  3.487 s]
> [INFO] ignite-aop . SUCCESS [
>  3.365 s]
> [INFO] ignite-ssh . SUCCESS [
>  3.135 s]
> [INFO] ignite-jta . SUCCESS [
>  3.762 s]
> [INFO] ignite-aws . SUCCESS [
>  3.550 s]
> [INFO] ignite-log4j2 .. SUCCESS [
>  3.074 s]
> [INFO] ignite-slf4j ... SUCCESS [
>  2.650 s]
> [INFO] ignite-jcl . SUCCESS [
>  2.515 s]
> [INFO] ignite-codegen . SUCCESS [
>  2.364 s]
> [INFO] ignite-gce . SUCCESS [
>  2.713 s]
> [INFO] ignite-cloud ... SUCCESS [
>  4.806 s]
> [INFO] ignite-mesos ... SUCCESS [
>  4.260 s]
> [INFO] ignite-kafka ... SUCCESS [
>  4.889 s]
> [INFO] ignite-flume ... SUCCESS [
>  3.584 s]
> [INFO] ignite-yarn  SUCCESS [
> 10.306 s]
> [INFO] ignite-jms11 ... SUCCESS [
>  3.234 s]
> [INFO] ignite-twitter . SUCCESS [
>  3.141 s]
> [INFO] ignite-mqtt  SUCCESS [
>  3.578 s]
> [INFO] ignite-zookeeper ... SUCCESS [
>  3.395 s]
> [INFO] ignite-camel ... SUCCESS [
>  3.579 s]
> [INFO] ignite-storm ... SUCCESS [
>  3.147 s]
> [INFO] ignite-osgi-paxlogging . SUCCESS [
>  0.728 s]
> [INFO] ignite-osgi-karaf .. SUCCESS [
>  0.381 s]
> [INFO] ignite-osgi  SUCCESS [
>  4.074 s]
> [INFO] ignite-appserver-test .. SUCCESS [
>  0.591 s]
> [INFO] ignite-websphere-test .. SUCCESS [
>  3.345 s]
> [INFO] ignite-cassandra ... SUCCESS [
>  0.355 s]
> [INFO] ignite-cassandra-store . SUCCESS [
> 10.290 s]
> [INFO] ignite-cassandra-serializers ... SUCCESS [
>  3.740 s]
> [INFO] ignite-flink ... SUCCESS [
>  3.553 s]
> [INFO] ignite-kubernetes .. SUCCESS [
>  2.646 s]
> [INFO] ignite-zeromq .. SUCCESS [
>  2.621 s]
> [INFO] ignite-scalar .. SUCCESS [
> 32.786 s]
> [INFO] ignite-spark ... SUCCESS [
> 12.782 s]
> [INFO] ignite-visor-console ... SUCCESS [
> 33.341 s]
> [INFO] ignite-visor-plugins 

Re: CREATE TABLE SQL command syntax

[Sergi Vladykin]

Sergey,

We've already discussed this and decided to have a cache per table, because
otherwise user will be forced to have unique keys across multiple
independent tables, which is bad.

Thus the idea with TABLESPACE does not really work for us.

Sergi

2017-04-12 13:15 GMT+03:00 Sergi Vladykin :

> I don't see how you make H2 Parser extendable, you will have to add plugin
> call to every *potentially* extendable place in it. In general this does
> not work. As H2 guy I would also reject patch like this.
>
> Sergi
>
> 2017-04-12 13:10 GMT+03:00 Alexander Paschenko <
> alexander.a.pasche...@gmail.com>:
>
>> Sergi,
>>
>> Please have a closer look at what I've written in my first post. I don't
>> see why we have to cling to H2 and its parsing modes all the time — after
>> all, we're just talking string processing now, aren't we? (Yes, complex
>> and
>> non trivial, but still.)
>>
>> What's wrong with idea of patching H2 to allow custom parsing? (With the
>> parsing itself living in Ignite code, obviously, not in H2.).
>>
>> What I propose is just to make H2's Parser class extendable and make H2
>> aware of its descendants via config params. And that's all with respect to
>> H2, nothing more.
>>
>> After that, on Ignite side we do all we want with our parser based on
>> theirs. It resembles story with custom types — first we make H2 extendable
>> in the way we need, then we introduce exact features we need on Ignite
>> side.
>>
>> — Alex
>>
>> среда, 12 апреля 2017 г. пользователь Sergi Vladykin написал:
>>
>> > It definitely makes sense to add a separate mode for Ignite in H2.
>> Though
>> > it is wrong to think that it will allow us to add any crazy syntax we
>> want
>> > (and it is actually a wrong idea imo), only the minor variations of the
>> > existing syntax. But this must be enough.
>> >
>> > I believe we should end up with something like
>> >
>> > CREATE TABLE person
>> > (
>> >   id INT PRIMARY KEY,
>> >   orgId INT AFFINITY KEY,
>> >   name VARCHAR
>> > )
>> > WITH "cfg:my_config_template.xml"
>> >
>> > Sergi
>> >
>> >
>> > 2017-04-12 7:54 GMT+03:00 Dmitriy Setrakyan > > >:
>> >
>> > > Agree, the updated syntax looks better. One change though: KEY ->
>> PRIMARY
>> > > KEY.
>> > >
>> > > Sergi, what do you think?
>> > >
>> > > D.
>> > >
>> > > On Tue, Apr 11, 2017 at 9:50 PM, Pavel Tupitsyn > > >
>> > > wrote:
>> > >
>> > > > I think "WITH" syntax is ugly and cumbersome.
>> > > >
>> > > > We should go with this one:
>> > > > CREATE TABLE Person (id int AFFINITY KEY, uid uuid KEY, firstName
>> > > > varchar, lastName varchar)
>> > > >
>> > > > All databases (i.e. [1], [2]) work this way, I see no reason to
>> invent
>> > > > something different and confuse the users.
>> > > >
>> > > > [1]
>> > > > https://docs.microsoft.com/en-us/sql/t-sql/statements/create
>> > > > -table-transact-sql#syntax-1
>> > > > [2] https://www.postgresql.org/docs/9.1/static/sql-createtable.html
>> > > >
>> > > > On Wed, Apr 12, 2017 at 6:12 AM, Alexander Paschenko <
>> > > > alexander.a.pasche...@gmail.com > wrote:
>> > > >
>> > > > > Dmitry,
>> > > > >
>> > > > > For H2 it would be something like this - please note all those
>> > quotes,
>> > > > > commas and equality signs that would be mandatory:
>> > > > >
>> > > > > CREATE TABLE Person (id int, uid uuid, firstName varchar, lastName
>> > > > > varchar) WITH "keyFields=id,uuid","affinityKey=id"
>> > > > >
>> > > > > With suggested approach, it would be something like
>> > > > >
>> > > > > CREATE TABLE Person (id int AFFINITY KEY, uid uuid KEY, firstName
>> > > > > varchar, lastName varchar)
>> > > > >
>> > > > > While this may not look like a drastic improvement in this
>> particular
>> > > > > case, we someday most likely will want either an all-custom CREATE
>> > > > > CACHE command, or a whole bunch of new options for CREATE TABLE,
>> if
>> > we
>> > > > > decide not to go with CREATE CACHE - I personally think that stuff
>> > > > > like
>> > > > >
>> > > > > CREATE TABLE ... WITH
>> > > > > "keyFields=id,uuid","affinityKey=id","cacheType=
>> > > partitioned","atomicity=
>> > > > > atomic","partitions=3"
>> > > > >
>> > > > > which will arise if we continue to try to stuff everything into
>> WITH
>> > > > > will just bring more ugliness with time, and that's not to mention
>> > > > > that new CREATE CACHE syntax will be impossible or relatively
>> hard to
>> > > > > introduce as we will have to approve it with H2 folks, and that's
>> how
>> > > > > it will be with any new param or command that we want.
>> > > > >
>> > > > > Allowing to plug custom parser into H2 (as we do now with table
>> > > > > engine) will let us introduce any syntax we want and focus on
>> > > > > usability and not on compromises and workarounds (which WITH
>> keyword
>> > > > > currently is).
>> > > > >
>> > > > > - Alex
>> > > > >
>> > > > > 2017-04-12 5:11 GMT+03:00 Dmitriy 

Re: CREATE TABLE SQL command syntax

[Sergi Vladykin]

I don't see how you make H2 Parser extendable, you will have to add plugin
call to every *potentially* extendable place in it. In general this does
not work. As H2 guy I would also reject patch like this.

Sergi

2017-04-12 13:10 GMT+03:00 Alexander Paschenko <
alexander.a.pasche...@gmail.com>:

> Sergi,
>
> Please have a closer look at what I've written in my first post. I don't
> see why we have to cling to H2 and its parsing modes all the time — after
> all, we're just talking string processing now, aren't we? (Yes, complex and
> non trivial, but still.)
>
> What's wrong with idea of patching H2 to allow custom parsing? (With the
> parsing itself living in Ignite code, obviously, not in H2.).
>
> What I propose is just to make H2's Parser class extendable and make H2
> aware of its descendants via config params. And that's all with respect to
> H2, nothing more.
>
> After that, on Ignite side we do all we want with our parser based on
> theirs. It resembles story with custom types — first we make H2 extendable
> in the way we need, then we introduce exact features we need on Ignite
> side.
>
> — Alex
>
> среда, 12 апреля 2017 г. пользователь Sergi Vladykin написал:
>
> > It definitely makes sense to add a separate mode for Ignite in H2. Though
> > it is wrong to think that it will allow us to add any crazy syntax we
> want
> > (and it is actually a wrong idea imo), only the minor variations of the
> > existing syntax. But this must be enough.
> >
> > I believe we should end up with something like
> >
> > CREATE TABLE person
> > (
> >   id INT PRIMARY KEY,
> >   orgId INT AFFINITY KEY,
> >   name VARCHAR
> > )
> > WITH "cfg:my_config_template.xml"
> >
> > Sergi
> >
> >
> > 2017-04-12 7:54 GMT+03:00 Dmitriy Setrakyan  > >:
> >
> > > Agree, the updated syntax looks better. One change though: KEY ->
> PRIMARY
> > > KEY.
> > >
> > > Sergi, what do you think?
> > >
> > > D.
> > >
> > > On Tue, Apr 11, 2017 at 9:50 PM, Pavel Tupitsyn  > >
> > > wrote:
> > >
> > > > I think "WITH" syntax is ugly and cumbersome.
> > > >
> > > > We should go with this one:
> > > > CREATE TABLE Person (id int AFFINITY KEY, uid uuid KEY, firstName
> > > > varchar, lastName varchar)
> > > >
> > > > All databases (i.e. [1], [2]) work this way, I see no reason to
> invent
> > > > something different and confuse the users.
> > > >
> > > > [1]
> > > > https://docs.microsoft.com/en-us/sql/t-sql/statements/create
> > > > -table-transact-sql#syntax-1
> > > > [2] https://www.postgresql.org/docs/9.1/static/sql-createtable.html
> > > >
> > > > On Wed, Apr 12, 2017 at 6:12 AM, Alexander Paschenko <
> > > > alexander.a.pasche...@gmail.com > wrote:
> > > >
> > > > > Dmitry,
> > > > >
> > > > > For H2 it would be something like this - please note all those
> > quotes,
> > > > > commas and equality signs that would be mandatory:
> > > > >
> > > > > CREATE TABLE Person (id int, uid uuid, firstName varchar, lastName
> > > > > varchar) WITH "keyFields=id,uuid","affinityKey=id"
> > > > >
> > > > > With suggested approach, it would be something like
> > > > >
> > > > > CREATE TABLE Person (id int AFFINITY KEY, uid uuid KEY, firstName
> > > > > varchar, lastName varchar)
> > > > >
> > > > > While this may not look like a drastic improvement in this
> particular
> > > > > case, we someday most likely will want either an all-custom CREATE
> > > > > CACHE command, or a whole bunch of new options for CREATE TABLE, if
> > we
> > > > > decide not to go with CREATE CACHE - I personally think that stuff
> > > > > like
> > > > >
> > > > > CREATE TABLE ... WITH
> > > > > "keyFields=id,uuid","affinityKey=id","cacheType=
> > > partitioned","atomicity=
> > > > > atomic","partitions=3"
> > > > >
> > > > > which will arise if we continue to try to stuff everything into
> WITH
> > > > > will just bring more ugliness with time, and that's not to mention
> > > > > that new CREATE CACHE syntax will be impossible or relatively hard
> to
> > > > > introduce as we will have to approve it with H2 folks, and that's
> how
> > > > > it will be with any new param or command that we want.
> > > > >
> > > > > Allowing to plug custom parser into H2 (as we do now with table
> > > > > engine) will let us introduce any syntax we want and focus on
> > > > > usability and not on compromises and workarounds (which WITH
> keyword
> > > > > currently is).
> > > > >
> > > > > - Alex
> > > > >
> > > > > 2017-04-12 5:11 GMT+03:00 Dmitriy Setrakyan  > >:
> > > > > > Alexeander,
> > > > > >
> > > > > > Can you please provide an example of what the CREATE TABLE
> command
> > > > would
> > > > > > look like if we use WITH syntax from H2 vs. what you are
> proposing?
> > > > > >
> > > > > > D.
> > > > > >
> > > > > > On Tue, Apr 11, 2017 at 6:35 PM, Alexander Paschenko <
> > > > > > alexander.a.pasche...@gmail.com > wrote:
> > > > > >
> > > > > >> Hello 

Re: CREATE TABLE SQL command syntax

[Alexander Paschenko]

Sergi,

Please have a closer look at what I've written in my first post. I don't
see why we have to cling to H2 and its parsing modes all the time — after
all, we're just talking string processing now, aren't we? (Yes, complex and
non trivial, but still.)

What's wrong with idea of patching H2 to allow custom parsing? (With the
parsing itself living in Ignite code, obviously, not in H2.).

What I propose is just to make H2's Parser class extendable and make H2
aware of its descendants via config params. And that's all with respect to
H2, nothing more.

After that, on Ignite side we do all we want with our parser based on
theirs. It resembles story with custom types — first we make H2 extendable
in the way we need, then we introduce exact features we need on Ignite side.

— Alex

среда, 12 апреля 2017 г. пользователь Sergi Vladykin написал:

> It definitely makes sense to add a separate mode for Ignite in H2. Though
> it is wrong to think that it will allow us to add any crazy syntax we want
> (and it is actually a wrong idea imo), only the minor variations of the
> existing syntax. But this must be enough.
>
> I believe we should end up with something like
>
> CREATE TABLE person
> (
>   id INT PRIMARY KEY,
>   orgId INT AFFINITY KEY,
>   name VARCHAR
> )
> WITH "cfg:my_config_template.xml"
>
> Sergi
>
>
> 2017-04-12 7:54 GMT+03:00 Dmitriy Setrakyan  >:
>
> > Agree, the updated syntax looks better. One change though: KEY -> PRIMARY
> > KEY.
> >
> > Sergi, what do you think?
> >
> > D.
> >
> > On Tue, Apr 11, 2017 at 9:50 PM, Pavel Tupitsyn  >
> > wrote:
> >
> > > I think "WITH" syntax is ugly and cumbersome.
> > >
> > > We should go with this one:
> > > CREATE TABLE Person (id int AFFINITY KEY, uid uuid KEY, firstName
> > > varchar, lastName varchar)
> > >
> > > All databases (i.e. [1], [2]) work this way, I see no reason to invent
> > > something different and confuse the users.
> > >
> > > [1]
> > > https://docs.microsoft.com/en-us/sql/t-sql/statements/create
> > > -table-transact-sql#syntax-1
> > > [2] https://www.postgresql.org/docs/9.1/static/sql-createtable.html
> > >
> > > On Wed, Apr 12, 2017 at 6:12 AM, Alexander Paschenko <
> > > alexander.a.pasche...@gmail.com > wrote:
> > >
> > > > Dmitry,
> > > >
> > > > For H2 it would be something like this - please note all those
> quotes,
> > > > commas and equality signs that would be mandatory:
> > > >
> > > > CREATE TABLE Person (id int, uid uuid, firstName varchar, lastName
> > > > varchar) WITH "keyFields=id,uuid","affinityKey=id"
> > > >
> > > > With suggested approach, it would be something like
> > > >
> > > > CREATE TABLE Person (id int AFFINITY KEY, uid uuid KEY, firstName
> > > > varchar, lastName varchar)
> > > >
> > > > While this may not look like a drastic improvement in this particular
> > > > case, we someday most likely will want either an all-custom CREATE
> > > > CACHE command, or a whole bunch of new options for CREATE TABLE, if
> we
> > > > decide not to go with CREATE CACHE - I personally think that stuff
> > > > like
> > > >
> > > > CREATE TABLE ... WITH
> > > > "keyFields=id,uuid","affinityKey=id","cacheType=
> > partitioned","atomicity=
> > > > atomic","partitions=3"
> > > >
> > > > which will arise if we continue to try to stuff everything into WITH
> > > > will just bring more ugliness with time, and that's not to mention
> > > > that new CREATE CACHE syntax will be impossible or relatively hard to
> > > > introduce as we will have to approve it with H2 folks, and that's how
> > > > it will be with any new param or command that we want.
> > > >
> > > > Allowing to plug custom parser into H2 (as we do now with table
> > > > engine) will let us introduce any syntax we want and focus on
> > > > usability and not on compromises and workarounds (which WITH keyword
> > > > currently is).
> > > >
> > > > - Alex
> > > >
> > > > 2017-04-12 5:11 GMT+03:00 Dmitriy Setrakyan  >:
> > > > > Alexeander,
> > > > >
> > > > > Can you please provide an example of what the CREATE TABLE command
> > > would
> > > > > look like if we use WITH syntax from H2 vs. what you are proposing?
> > > > >
> > > > > D.
> > > > >
> > > > > On Tue, Apr 11, 2017 at 6:35 PM, Alexander Paschenko <
> > > > > alexander.a.pasche...@gmail.com > wrote:
> > > > >
> > > > >> Hello Igniters,
> > > > >>
> > > > >> Yup, it's THAT time once again as we haven't ultimately settled on
> > > > >> anything with the subj. as of yet, but I believe that now with DDL
> > on
> > > > >> its way this talk can't be avoided anymore (sorry guys).
> > > > >>
> > > > >> The last time we talked about Ignite specific stuff we need to
> have
> > in
> > > > >> CREATE TABLE (key fields list, affinity key, am I missing
> > anything?),
> > > > >> the simplest approach suggested by Sergi was that we simply use
> WITH
> > > > >> part of H2's CREATE TABLE to pass 

Re: CREATE TABLE SQL command syntax

[Sergey Kozlov]

Hi

I think we should introduce less new syntax for SQL for existing general
statements especially inside brackets. It will simplify the migration from
a RDBMS to Ignite.

Personally I like idea to have CREATE CACHE syntax which similar CREATE
PARTITION for MS [1] or CREATE TABLESPACE for MySQL [2] where we can define
any specific Ignite cache options and just use CREATE TABLE ... WITH
CACHE=cache_name

[1]
https://docs.microsoft.com/en-us/sql/t-sql/statements/create-partition-scheme-transact-sql
[2] https://dev.mysql.com/doc/refman/5.7/en/create-tablespace.html

On Wed, Apr 12, 2017 at 11:37 AM, Sergi Vladykin 
wrote:

> It definitely makes sense to add a separate mode for Ignite in H2. Though
> it is wrong to think that it will allow us to add any crazy syntax we want
> (and it is actually a wrong idea imo), only the minor variations of the
> existing syntax. But this must be enough.
>
> I believe we should end up with something like
>
> CREATE TABLE person
> (
>   id INT PRIMARY KEY,
>   orgId INT AFFINITY KEY,
>   name VARCHAR
> )
> WITH "cfg:my_config_template.xml"
>
> Sergi
>
>
> 2017-04-12 7:54 GMT+03:00 Dmitriy Setrakyan :
>
> > Agree, the updated syntax looks better. One change though: KEY -> PRIMARY
> > KEY.
> >
> > Sergi, what do you think?
> >
> > D.
> >
> > On Tue, Apr 11, 2017 at 9:50 PM, Pavel Tupitsyn 
> > wrote:
> >
> > > I think "WITH" syntax is ugly and cumbersome.
> > >
> > > We should go with this one:
> > > CREATE TABLE Person (id int AFFINITY KEY, uid uuid KEY, firstName
> > > varchar, lastName varchar)
> > >
> > > All databases (i.e. [1], [2]) work this way, I see no reason to invent
> > > something different and confuse the users.
> > >
> > > [1]
> > > https://docs.microsoft.com/en-us/sql/t-sql/statements/create
> > > -table-transact-sql#syntax-1
> > > [2] https://www.postgresql.org/docs/9.1/static/sql-createtable.html
> > >
> > > On Wed, Apr 12, 2017 at 6:12 AM, Alexander Paschenko <
> > > alexander.a.pasche...@gmail.com> wrote:
> > >
> > > > Dmitry,
> > > >
> > > > For H2 it would be something like this - please note all those
> quotes,
> > > > commas and equality signs that would be mandatory:
> > > >
> > > > CREATE TABLE Person (id int, uid uuid, firstName varchar, lastName
> > > > varchar) WITH "keyFields=id,uuid","affinityKey=id"
> > > >
> > > > With suggested approach, it would be something like
> > > >
> > > > CREATE TABLE Person (id int AFFINITY KEY, uid uuid KEY, firstName
> > > > varchar, lastName varchar)
> > > >
> > > > While this may not look like a drastic improvement in this particular
> > > > case, we someday most likely will want either an all-custom CREATE
> > > > CACHE command, or a whole bunch of new options for CREATE TABLE, if
> we
> > > > decide not to go with CREATE CACHE - I personally think that stuff
> > > > like
> > > >
> > > > CREATE TABLE ... WITH
> > > > "keyFields=id,uuid","affinityKey=id","cacheType=
> > partitioned","atomicity=
> > > > atomic","partitions=3"
> > > >
> > > > which will arise if we continue to try to stuff everything into WITH
> > > > will just bring more ugliness with time, and that's not to mention
> > > > that new CREATE CACHE syntax will be impossible or relatively hard to
> > > > introduce as we will have to approve it with H2 folks, and that's how
> > > > it will be with any new param or command that we want.
> > > >
> > > > Allowing to plug custom parser into H2 (as we do now with table
> > > > engine) will let us introduce any syntax we want and focus on
> > > > usability and not on compromises and workarounds (which WITH keyword
> > > > currently is).
> > > >
> > > > - Alex
> > > >
> > > > 2017-04-12 5:11 GMT+03:00 Dmitriy Setrakyan :
> > > > > Alexeander,
> > > > >
> > > > > Can you please provide an example of what the CREATE TABLE command
> > > would
> > > > > look like if we use WITH syntax from H2 vs. what you are proposing?
> > > > >
> > > > > D.
> > > > >
> > > > > On Tue, Apr 11, 2017 at 6:35 PM, Alexander Paschenko <
> > > > > alexander.a.pasche...@gmail.com> wrote:
> > > > >
> > > > >> Hello Igniters,
> > > > >>
> > > > >> Yup, it's THAT time once again as we haven't ultimately settled on
> > > > >> anything with the subj. as of yet, but I believe that now with DDL
> > on
> > > > >> its way this talk can't be avoided anymore (sorry guys).
> > > > >>
> > > > >> The last time we talked about Ignite specific stuff we need to
> have
> > in
> > > > >> CREATE TABLE (key fields list, affinity key, am I missing
> > anything?),
> > > > >> the simplest approach suggested by Sergi was that we simply use
> WITH
> > > > >> part of H2's CREATE TABLE to pass stuff we need.
> > > > >>
> > > > >> This could work, but needless to say that such commands would look
> > > plain
> > > > >> ugly.
> > > > >>
> > > > >> I think we should go with custom syntax after all, BUT not in a
> way
> > > > >> suggested before by Sergi (propose Apache 

[GitHub] ignite pull request #1693: Ignite 4876

[kdudkov]

Github user kdudkov closed the pull request at:

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


---
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 #1464: Ignite-4571 futId

[kdudkov]

Github user kdudkov closed the pull request at:

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


---
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.
---

Session expiration in Cassandra store

[Valentin Kulichenko]

Hi Igor,

I recently faced an issue with Cassandra store closing idle connections
after some time. While investigating I found that this is caused by
SessionPool and its SessionMonitor thread which closes sessions that were
not acquired from the pool within 5 minutes.

I have several questions regarding this:

   - What is the general idea behind this?
   - Why the timeout is not configurable?
   - Is it possible to add an option to disable this thread completely?
   Will this have any drawbacks?

-Val

SQL on PARTITIONED vs REPLICATED cache

[Sergi Vladykin]

Guys,

I want to introduce another breaking change for 2.0.

Currently SQL is being processed differently when we call method `query` on
partitioned cache and on replicated: on replicated cache we do not do any
extra processing and execute the query as is on current node.

This behavior historically existed for performance reasons. But it is not
obvious and leads to wrong query results. This issue becomes even more
creepy with JDBC and ODBC drivers.

In 2.0 I want to execute all the SQL queries the same way through the whole
processing pipeline to guaranty the correct result irrespectively to the
cache that was the query originator.

To be able to have the old behavior (skip all the preprocessing and run
query on current node) add a flag isReplicatedOnly() on SqlQuery and
SqlFieldsQuery. It will be disabled by default and if one knows that the
only replicated tables participate in a query, then he can enable it for
better performance.

Sergi

build failure in the master branch

[Vyacheslav Daradur]

Last commit [1] 12.04.2017 6:19:06

mvn -X clean package -DskipTests

result:
***
[DEBUG] parsing done in 2ms.
JavaDoc error: 'Other Packages' section should not be present, all packages
shou
ld have corresponding documentation groups:
C:\Users\SBT-Daradur-V\Projects\igni
te\target\javadoc\core/overview-summary.html
[DEBUG] parsing started
[DEBUG] DomTree builder started.
[DEBUG] LagartoDom tree created in 4 ms.
[DEBUG] parsing done in 5ms.
[DEBUG] parsing started
[DEBUG] DomTree builder started.
[DEBUG] LagartoDom tree created in 4 ms.
[DEBUG] parsing done in 4ms.
[INFO]

[INFO] Reactor Summary:
[INFO]
[INFO] ignite-apache-license-gen .. SUCCESS [
 1.473 s]
[INFO] ignite-tools ... SUCCESS [
 5.950 s]
[INFO] ignite-core  SUCCESS [02:25
min]
[INFO] ignite-log4j ... SUCCESS [
 4.440 s]
[INFO] ignite-indexing  SUCCESS [
12.198 s]
[INFO] ignite-urideploy ... SUCCESS [
 4.338 s]
[INFO] ignite-spring .. SUCCESS [
 5.500 s]
[INFO] ignite-hadoop .. SUCCESS [
15.860 s]
[INFO] ignite-extdata-p2p . SUCCESS [
 4.629 s]
[INFO] ignite-extdata-uri-dep . SUCCESS [
 2.210 s]
[INFO] ignite-extdata-uri . SUCCESS [
 1.033 s]
[INFO] ignite-rest-http ... SUCCESS [
 4.003 s]
[INFO] ignite-clients . SUCCESS [
 2.153 s]
[INFO] ignite-spring-data . SUCCESS [
 3.284 s]
[INFO] ignite-web . SUCCESS [
 3.487 s]
[INFO] ignite-aop . SUCCESS [
 3.365 s]
[INFO] ignite-ssh . SUCCESS [
 3.135 s]
[INFO] ignite-jta . SUCCESS [
 3.762 s]
[INFO] ignite-aws . SUCCESS [
 3.550 s]
[INFO] ignite-log4j2 .. SUCCESS [
 3.074 s]
[INFO] ignite-slf4j ... SUCCESS [
 2.650 s]
[INFO] ignite-jcl . SUCCESS [
 2.515 s]
[INFO] ignite-codegen . SUCCESS [
 2.364 s]
[INFO] ignite-gce . SUCCESS [
 2.713 s]
[INFO] ignite-cloud ... SUCCESS [
 4.806 s]
[INFO] ignite-mesos ... SUCCESS [
 4.260 s]
[INFO] ignite-kafka ... SUCCESS [
 4.889 s]
[INFO] ignite-flume ... SUCCESS [
 3.584 s]
[INFO] ignite-yarn  SUCCESS [
10.306 s]
[INFO] ignite-jms11 ... SUCCESS [
 3.234 s]
[INFO] ignite-twitter . SUCCESS [
 3.141 s]
[INFO] ignite-mqtt  SUCCESS [
 3.578 s]
[INFO] ignite-zookeeper ... SUCCESS [
 3.395 s]
[INFO] ignite-camel ... SUCCESS [
 3.579 s]
[INFO] ignite-storm ... SUCCESS [
 3.147 s]
[INFO] ignite-osgi-paxlogging . SUCCESS [
 0.728 s]
[INFO] ignite-osgi-karaf .. SUCCESS [
 0.381 s]
[INFO] ignite-osgi  SUCCESS [
 4.074 s]
[INFO] ignite-appserver-test .. SUCCESS [
 0.591 s]
[INFO] ignite-websphere-test .. SUCCESS [
 3.345 s]
[INFO] ignite-cassandra ... SUCCESS [
 0.355 s]
[INFO] ignite-cassandra-store . SUCCESS [
10.290 s]
[INFO] ignite-cassandra-serializers ... SUCCESS [
 3.740 s]
[INFO] ignite-flink ... SUCCESS [
 3.553 s]
[INFO] ignite-kubernetes .. SUCCESS [
 2.646 s]
[INFO] ignite-zeromq .. SUCCESS [
 2.621 s]
[INFO] ignite-scalar .. SUCCESS [
32.786 s]
[INFO] ignite-spark ... SUCCESS [
12.782 s]
[INFO] ignite-visor-console ... SUCCESS [
33.341 s]
[INFO] ignite-visor-plugins ... SUCCESS [
 2.912 s]
[INFO] apache-ignite .. FAILURE [
50.691 s]
[INFO]

[INFO] BUILD FAILURE
[INFO]

[INFO] Total time: 07:37 min
[INFO] Finished at: 

Re: CachePojoStore data loading with binary marshaller

[Valentin Kulichenko]

Yes, that's my thinking as well.

-Val

On Wed, Apr 12, 2017 at 10:59 AM, Dmitriy Govorukhin <
dmitriy.govoruk...@gmail.com> wrote:

> Hi Valentin,
>
> Other word, are you agree with me? My point that we always must use binary
> representation if binary marshaller enable.
>
> On Wed, Apr 12, 2017 at 10:24 AM, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > Hi Dmitry,
> >
> > I can't advise a lot on implementation details, but generally I don't
> think
> > that CacheJdbcPojoStore should ever work with POJO classes in case binary
> > marshaller is enabled. It should always work directly with binary objects
> > even if POJOs are on server classpath, and switch to POJOs only when
> other
> > marshaller is used.
> >
> > Makes sense?
> >
> > -Val
> >
> > On Tue, Apr 11, 2017 at 12:06 PM, Dmitriy Govorukhin <
> > dmitriy.govoruk...@gmail.com> wrote:
> >
> > > Hi all,
> > >
> > > I found problem related to CacheJdbcPojoStore. If try to load data,
> with
> > > enabled binary marshaller,
> > > error may occur. Problem in entryMappings (this map helps resolve
> stored
> > > type when data loading).
> > > If binary marshaller disable we just  put entry with java type in this
> > map,
> > > if enable we put java type + binary type.
> > >
> > > ..
> > >
> > >checkTypeConfiguration(cacheName, valKind, valType,
> > > type.getValueFields());
> > >
> > >entryMappings.put(keyTypeId, new EntryMapping(cacheName, dialect,
> > type,
> > > keyKind, valKind, sqlEscapeAll));
> > >
> > >// Add one more binding to binary typeId for POJOs,
> > >// because object could be passed to store in binary format.
> > >if (binarySupported && keyKind == TypeKind.POJO) {
> > >keyTypeId = typeIdForTypeName(TypeKind.BINARY, keyType);
> > >
> > >valKind = valKind == TypeKind.POJO ? TypeKind.BINARY : valKind;
> > >
> > >entryMappings.put(keyTypeId, new EntryMapping(cacheName,
> dialect,
> > > type, TypeKind.BINARY, valKind, sqlEscapeAll));
> > > }
> > >
> > > ...
> > >
> > >
> > > I think it is wrong, because after we use this map like  iterator for
> > load,
> > > and final result dependent from which mapping will be first java or
> > binary.
> > >
> > > Collection processedKeyTypes = new HashSet<>();
> > >
> > > for (EntryMapping em : mappings.values()) {
> > > String keyType = em.keyType();
> > >
> > > if (processedKeyTypes.contains(keyType))
> > > continue;
> > >
> > > processedKeyTypes.add(keyType);
> > >
> > > .
> > >
> > > I think we must add only binary mapping for user pojo if binary
> > marshaller
> > > enable.
> > >
> >
>

Re: CachePojoStore data loading with binary marshaller

[Dmitriy Govorukhin]

Hi Valentin,

Other word, are you agree with me? My point that we always must use binary
representation if binary marshaller enable.

On Wed, Apr 12, 2017 at 10:24 AM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Hi Dmitry,
>
> I can't advise a lot on implementation details, but generally I don't think
> that CacheJdbcPojoStore should ever work with POJO classes in case binary
> marshaller is enabled. It should always work directly with binary objects
> even if POJOs are on server classpath, and switch to POJOs only when other
> marshaller is used.
>
> Makes sense?
>
> -Val
>
> On Tue, Apr 11, 2017 at 12:06 PM, Dmitriy Govorukhin <
> dmitriy.govoruk...@gmail.com> wrote:
>
> > Hi all,
> >
> > I found problem related to CacheJdbcPojoStore. If try to load data, with
> > enabled binary marshaller,
> > error may occur. Problem in entryMappings (this map helps resolve stored
> > type when data loading).
> > If binary marshaller disable we just  put entry with java type in this
> map,
> > if enable we put java type + binary type.
> >
> > ..
> >
> >checkTypeConfiguration(cacheName, valKind, valType,
> > type.getValueFields());
> >
> >entryMappings.put(keyTypeId, new EntryMapping(cacheName, dialect,
> type,
> > keyKind, valKind, sqlEscapeAll));
> >
> >// Add one more binding to binary typeId for POJOs,
> >// because object could be passed to store in binary format.
> >if (binarySupported && keyKind == TypeKind.POJO) {
> >keyTypeId = typeIdForTypeName(TypeKind.BINARY, keyType);
> >
> >valKind = valKind == TypeKind.POJO ? TypeKind.BINARY : valKind;
> >
> >entryMappings.put(keyTypeId, new EntryMapping(cacheName, dialect,
> > type, TypeKind.BINARY, valKind, sqlEscapeAll));
> > }
> >
> > ...
> >
> >
> > I think it is wrong, because after we use this map like  iterator for
> load,
> > and final result dependent from which mapping will be first java or
> binary.
> >
> > Collection processedKeyTypes = new HashSet<>();
> >
> > for (EntryMapping em : mappings.values()) {
> > String keyType = em.keyType();
> >
> > if (processedKeyTypes.contains(keyType))
> > continue;
> >
> > processedKeyTypes.add(keyType);
> >
> > .
> >
> > I think we must add only binary mapping for user pojo if binary
> marshaller
> > enable.
> >
>

Re: Sorting fields of Binarilyzable objects on write

[Sergi Vladykin]

Vladimir,

I think we have to disallow conditional writes here, because DML should
write all the fields, no?

Sergi

2017-04-12 11:07 GMT+03:00 Vladimir Ozerov :

> Consider the following code:
>
> void writeBinary(BinaryWriter w) {
> w.writeBoolean("C", c);
>
> if (c)
> w.writeInt("A", a)
> else
> w.writeInt("B", b)
> }
>
> How are we going to force user to follow the contract in this case?
>
> On Wed, Apr 12, 2017 at 9:16 AM, Dmitriy Setrakyan 
> wrote:
>
> > I think it is OK for users to do their own sorting, but we should
> > definitely validate the correct order and throw an exception if it is
> not.
> >
> > D.
> >
> > On Tue, Apr 11, 2017 at 11:02 PM, Pavel Tupitsyn 
> > wrote:
> >
> > > QueryEntity order is not only harder for the users, it will be
> nightmare
> > to
> > > implement.
> > > What if there is no QueryEntity defined? What if the same class is used
> > in
> > > multiple QueryEntity?
> > > I don't think serialization code has to be tied to QueryEntity in any
> > way,
> > > this violates separation of concerns.
> > >
> > > So I guess we can agree on sorting fields alphabetically.
> > >
> > > Let's get to the initial question:
> > > * Should we do the sorting for the user (performance hit)?
> > > * Should we at least validate user-defined order?
> > >
> > > On Wed, Apr 12, 2017 at 2:12 AM, Dmitriy Setrakyan <
> > dsetrak...@apache.org>
> > > wrote:
> > >
> > > > On Tue, Apr 11, 2017 at 1:28 PM, Sergi Vladykin <
> > > sergi.vlady...@gmail.com>
> > > > wrote:
> > > >
> > > > > I'm just trying to understand the current state of things and
> risks.
> > > May
> > > > be
> > > > > we need to do some adjustments here before 2.0 to be on the safe
> > side.
> > > > >
> > > > > Actually looks like this not really important, we just have to
> > clearly
> > > > > document that DML builds keys this way and require from user to do
> > the
> > > > same
> > > > > to be able to use cache API.
> > > > >
> > > >
> > > >
> > > > I think it is important from the usability stand point. A user can
> > always
> > > > sort fields alphabetically in his or her mind. However, trying to
> > > remember
> > > > the field order from some QueryEntity is a lot harder.
> > > >
> > >
> >
>

Re: CREATE TABLE SQL command syntax

[Sergi Vladykin]

It definitely makes sense to add a separate mode for Ignite in H2. Though
it is wrong to think that it will allow us to add any crazy syntax we want
(and it is actually a wrong idea imo), only the minor variations of the
existing syntax. But this must be enough.

I believe we should end up with something like

CREATE TABLE person
(
  id INT PRIMARY KEY,
  orgId INT AFFINITY KEY,
  name VARCHAR
)
WITH "cfg:my_config_template.xml"

Sergi


2017-04-12 7:54 GMT+03:00 Dmitriy Setrakyan :

> Agree, the updated syntax looks better. One change though: KEY -> PRIMARY
> KEY.
>
> Sergi, what do you think?
>
> D.
>
> On Tue, Apr 11, 2017 at 9:50 PM, Pavel Tupitsyn 
> wrote:
>
> > I think "WITH" syntax is ugly and cumbersome.
> >
> > We should go with this one:
> > CREATE TABLE Person (id int AFFINITY KEY, uid uuid KEY, firstName
> > varchar, lastName varchar)
> >
> > All databases (i.e. [1], [2]) work this way, I see no reason to invent
> > something different and confuse the users.
> >
> > [1]
> > https://docs.microsoft.com/en-us/sql/t-sql/statements/create
> > -table-transact-sql#syntax-1
> > [2] https://www.postgresql.org/docs/9.1/static/sql-createtable.html
> >
> > On Wed, Apr 12, 2017 at 6:12 AM, Alexander Paschenko <
> > alexander.a.pasche...@gmail.com> wrote:
> >
> > > Dmitry,
> > >
> > > For H2 it would be something like this - please note all those quotes,
> > > commas and equality signs that would be mandatory:
> > >
> > > CREATE TABLE Person (id int, uid uuid, firstName varchar, lastName
> > > varchar) WITH "keyFields=id,uuid","affinityKey=id"
> > >
> > > With suggested approach, it would be something like
> > >
> > > CREATE TABLE Person (id int AFFINITY KEY, uid uuid KEY, firstName
> > > varchar, lastName varchar)
> > >
> > > While this may not look like a drastic improvement in this particular
> > > case, we someday most likely will want either an all-custom CREATE
> > > CACHE command, or a whole bunch of new options for CREATE TABLE, if we
> > > decide not to go with CREATE CACHE - I personally think that stuff
> > > like
> > >
> > > CREATE TABLE ... WITH
> > > "keyFields=id,uuid","affinityKey=id","cacheType=
> partitioned","atomicity=
> > > atomic","partitions=3"
> > >
> > > which will arise if we continue to try to stuff everything into WITH
> > > will just bring more ugliness with time, and that's not to mention
> > > that new CREATE CACHE syntax will be impossible or relatively hard to
> > > introduce as we will have to approve it with H2 folks, and that's how
> > > it will be with any new param or command that we want.
> > >
> > > Allowing to plug custom parser into H2 (as we do now with table
> > > engine) will let us introduce any syntax we want and focus on
> > > usability and not on compromises and workarounds (which WITH keyword
> > > currently is).
> > >
> > > - Alex
> > >
> > > 2017-04-12 5:11 GMT+03:00 Dmitriy Setrakyan :
> > > > Alexeander,
> > > >
> > > > Can you please provide an example of what the CREATE TABLE command
> > would
> > > > look like if we use WITH syntax from H2 vs. what you are proposing?
> > > >
> > > > D.
> > > >
> > > > On Tue, Apr 11, 2017 at 6:35 PM, Alexander Paschenko <
> > > > alexander.a.pasche...@gmail.com> wrote:
> > > >
> > > >> Hello Igniters,
> > > >>
> > > >> Yup, it's THAT time once again as we haven't ultimately settled on
> > > >> anything with the subj. as of yet, but I believe that now with DDL
> on
> > > >> its way this talk can't be avoided anymore (sorry guys).
> > > >>
> > > >> The last time we talked about Ignite specific stuff we need to have
> in
> > > >> CREATE TABLE (key fields list, affinity key, am I missing
> anything?),
> > > >> the simplest approach suggested by Sergi was that we simply use WITH
> > > >> part of H2's CREATE TABLE to pass stuff we need.
> > > >>
> > > >> This could work, but needless to say that such commands would look
> > plain
> > > >> ugly.
> > > >>
> > > >> I think we should go with custom syntax after all, BUT not in a way
> > > >> suggested before by Sergi (propose Apache Ignite mode to H2).
> > > >>
> > > >> Instead, I suggest that we propose to H2 patch that would allow
> > > >> plugging in *custom SQL parser* directly based on theirs (quite
> > > >> elegant one) – I've had a look at their code, and this should not be
> > > >> hard.
> > > >>
> > > >> Work on such a patch making syntax parsing overridable would take a
> > > >> couple days which is not much time AND would give us the opportunity
> > > >> to introduce to Ignite virtually any syntax we wish - both now and
> in
> > > >> the future. Without worrying about compatibility with H2 ever again,
> > > >> that is.
> > > >>
> > > >> Thoughts? After we agree on this principally and after H2 patch for
> > > >> custom parsing is ready, we can roll our sleeves and focus on syntax
> > > >> itself.
> > > >>
> > > >> - Alex
> > > >>
> > >
> >
>

question: How data are stored in IgniteCache?

[Vyacheslav Daradur]

Hello Igniters!

I have one conceptual question:

When we put an object in IgniteCache, how it is stored?

As I understand, after marshalling we have an array of bytes,
1) in a local node it is wrapped in BinaryObjectImpl and stored in memory
2) it is sent to remote node as byte array where it will be wrapped in
BinaryObjectImpl and be stored in memory

-- 
Best Regards, Vyacheslav

Re: Sorting fields of Binarilyzable objects on write

[Vladimir Ozerov]

Consider the following code:

void writeBinary(BinaryWriter w) {
w.writeBoolean("C", c);

if (c)
w.writeInt("A", a)
else
w.writeInt("B", b)
}

How are we going to force user to follow the contract in this case?

On Wed, Apr 12, 2017 at 9:16 AM, Dmitriy Setrakyan 
wrote:

> I think it is OK for users to do their own sorting, but we should
> definitely validate the correct order and throw an exception if it is not.
>
> D.
>
> On Tue, Apr 11, 2017 at 11:02 PM, Pavel Tupitsyn 
> wrote:
>
> > QueryEntity order is not only harder for the users, it will be nightmare
> to
> > implement.
> > What if there is no QueryEntity defined? What if the same class is used
> in
> > multiple QueryEntity?
> > I don't think serialization code has to be tied to QueryEntity in any
> way,
> > this violates separation of concerns.
> >
> > So I guess we can agree on sorting fields alphabetically.
> >
> > Let's get to the initial question:
> > * Should we do the sorting for the user (performance hit)?
> > * Should we at least validate user-defined order?
> >
> > On Wed, Apr 12, 2017 at 2:12 AM, Dmitriy Setrakyan <
> dsetrak...@apache.org>
> > wrote:
> >
> > > On Tue, Apr 11, 2017 at 1:28 PM, Sergi Vladykin <
> > sergi.vlady...@gmail.com>
> > > wrote:
> > >
> > > > I'm just trying to understand the current state of things and risks.
> > May
> > > be
> > > > we need to do some adjustments here before 2.0 to be on the safe
> side.
> > > >
> > > > Actually looks like this not really important, we just have to
> clearly
> > > > document that DML builds keys this way and require from user to do
> the
> > > same
> > > > to be able to use cache API.
> > > >
> > >
> > >
> > > I think it is important from the usability stand point. A user can
> always
> > > sort fields alphabetically in his or her mind. However, trying to
> > remember
> > > the field order from some QueryEntity is a lot harder.
> > >
> >
>

Re: TouchedExpiryPolicy works incorrect in some cases IGNITE-4401

[ALEKSEY KUZNETSOV]

I have already attached simlified version. Shall i simplify it more ?

вт, 11 апр. 2017 г. в 19:28, Denis Magda :

> Can you attach the simplified version? Just want to avoid any side effects.
>
> —
> Denis
>
> > On Apr 11, 2017, at 9:14 AM, ALEKSEY KUZNETSOV 
> wrote:
> >
> > I took it from https://issues.apache.org/jira/browse/IGNITE-4401 <
> https://issues.apache.org/jira/browse/IGNITE-4401> and simplified . See
> in attached
> >
> >
> > вт, 11 апр. 2017 г. в 19:03, Denis Magda >:
> > Hello,
> >
> > Do you have sample code?
> >
> > —
> > Denis
> > > On Apr 11, 2017, at 2:45 AM, ALEKSEY KUZNETSOV <
> alkuznetsov...@gmail.com > wrote:
> > >
> > > Hi, igniters!
> > > While doing https://issues.apache.org/jira/browse/IGNITE-4401 <
> https://issues.apache.org/jira/browse/IGNITE-4401> ticket i came
> > > across the fact that cache querying returns null , while cache still
> has
> > > got entry.
> > > Cache query : SELECT nameProp FROM EDUProp WHERE EDUId = 1
> > > Cache get operation : ignite().cache("eduPropCache").get(new
> AffinityKey("1",
> > > "1")) non-null
> > > I cannot even imagine what could be wrong with it.
> > >
> > >
> > >
> > > --
> > >
> > > *Best Regards,*
> > >
> > > *Kuznetsov Aleksey*
> >
> > --
> > Best Regards,
> >
> > Kuznetsov Aleksey
> >
>
> --

*Best Regards,*

*Kuznetsov Aleksey*

[GitHub] ignite pull request #1777: IGNITE-2398 .NET: Change default mapper behavior

[ptupitsyn]

GitHub user ptupitsyn opened a pull request:

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

IGNITE-2398 .NET: Change default mapper behavior



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

$ git pull https://github.com/ptupitsyn/ignite ignite-2398

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

https://github.com/apache/ignite/pull/1777.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 #1777


commit 389947517d5a9da82f2957ca6c188abee3ff1950
Author: Pavel Tupitsyn 
Date:   2017-04-06T09:12:28Z

IGNITE-2398 .NET: Change default mapper behavior

commit e8c5eb155b5b3a4ed3438bd07187bffd60da63d2
Author: Pavel Tupitsyn 
Date:   2017-04-07T05:02:22Z

Merge branch 'master' into ignite-2398

commit e3d02ffbd7ed4161208bd7320fc5aa330c795478
Author: Pavel Tupitsyn 
Date:   2017-04-07T05:54:56Z

wip

commit d03b099ad5664cf2fdd7f2fae7cca35ea42ef387
Author: Pavel Tupitsyn 
Date:   2017-04-07T06:10:12Z

Adding tests

commit d16b8e6ef6d1bb84e08a508bfda69c0955b2fcf6
Author: Pavel Tupitsyn 
Date:   2017-04-07T06:12:45Z

wip

commit ff624e11082fbc643ca63571ded2d20424b76bd5
Author: Pavel Tupitsyn 
Date:   2017-04-07T06:22:18Z

wip

commit 1984bfe487e71075ba14475c56d9b8ec11d2f9e0
Author: Pavel Tupitsyn 
Date:   2017-04-07T06:26:32Z

wip

commit 0259adde7701d5139340b27a78f8cf2a35820bca
Author: Pavel Tupitsyn 
Date:   2017-04-07T06:27:42Z

Mapper implemented

commit fdb92dfef0e54dfea405557f957bced17a0cf42c
Author: Pavel Tupitsyn 
Date:   2017-04-07T06:40:54Z

wip

commit dcbabd5e9e2590172acd5447fcf40452724ec98d
Author: Pavel Tupitsyn 
Date:   2017-04-07T06:42:54Z

wip

commit 41e75b7b1a82cc85abbe3d9b30ccb06a6ea5eb33
Author: Pavel Tupitsyn 
Date:   2017-04-07T08:07:59Z

wip

commit f9078a4be71b697146bbfd452eeadcfd6dd54b16
Author: Pavel Tupitsyn 
Date:   2017-04-07T08:27:27Z

wip

commit 62726158cb3ca7092fb9fa20c946f8612b7e50fc
Author: Pavel Tupitsyn 
Date:   2017-04-07T08:44:31Z

wip

commit cf5802362319cd9e2997874107393fd1761221f9
Author: Pavel Tupitsyn 
Date:   2017-04-07T08:57:22Z

wip

commit 48df244e753c998b79b482abeae27b2b4377
Author: Pavel Tupitsyn 
Date:   2017-04-07T09:31:29Z

wip

commit cac10fa6233bd541051c93af0662d52be809ed72
Author: Pavel Tupitsyn 
Date:   2017-04-07T09:45:51Z

wip

commit 1b085dff02469eeb25947ab6064e4fd5108db891
Author: Pavel Tupitsyn 
Date:   2017-04-07T09:49:57Z

wip

commit 283c145ad4251f3fa58d88b0c7b0d7ca3cab0b68
Author: Pavel Tupitsyn 
Date:   2017-04-07T10:26:35Z

wip

commit 93865a970dc60397304ce659ee718f4f13a19936
Author: Pavel Tupitsyn 
Date:   2017-04-07T11:06:37Z

wip

commit 9c053e6d9f7ed25f8784c431a293776649dd8152
Author: Pavel Tupitsyn 
Date:   2017-04-07T11:17:15Z

wip

commit 3c1b38a6979aed4116125a613f058a78dff694dc
Author: Pavel Tupitsyn 
Date:   2017-04-07T11:18:51Z

wip

commit b4f7dd7830207f3fa8b67ccddbe4c4196b1536e5
Author: Pavel Tupitsyn 
Date:   2017-04-07T11:37:36Z

wip

commit 44997da2750d4fea4eabc8777bac3bac0ed354db
Author: Pavel Tupitsyn 
Date:   2017-04-07T11:40:25Z

wip

commit e952c1e3d7a881c9889137970b7cfe1f59b0870e
Author: Pavel Tupitsyn 
Date:   2017-04-07T11:47:18Z

wip type name parser

commit 944e39fb15afee94655666f835723144102283de
Author: Pavel Tupitsyn 
Date:   2017-04-07T11:51:12Z

wip

commit e8df2acde61abd8d853e1ae6b9329736b1f241af
Author: Pavel Tupitsyn 
Date:   2017-04-07T11:56:16Z

wip

commit 5e6ae293e96826131a9dcba2ffa39519df35afd2
Author: Pavel Tupitsyn 
Date:   2017-04-07T11:57:06Z

wip tests

commit d9ec783459b1b87e125ca96c99defad474ff5cb6
Author: Pavel Tupitsyn 
Date:   2017-04-07T11:59:23Z

wip

commit 7c6b6dc6610b5f17fb25e0eba3d20bb45fdb2b84
Author: Pavel Tupitsyn 
Date:   2017-04-07T12:05:59Z

wip

commit 4c8172fba6753749521b58c9c74004ffedde8e7d
Author: Pavel Tupitsyn 
Date:   2017-04-07T12:07:53Z

wip




---
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

Re: Sorting fields of Binarilyzable objects on write

[Dmitriy Setrakyan]

I think it is OK for users to do their own sorting, but we should
definitely validate the correct order and throw an exception if it is not.

D.

On Tue, Apr 11, 2017 at 11:02 PM, Pavel Tupitsyn 
wrote:

> QueryEntity order is not only harder for the users, it will be nightmare to
> implement.
> What if there is no QueryEntity defined? What if the same class is used in
> multiple QueryEntity?
> I don't think serialization code has to be tied to QueryEntity in any way,
> this violates separation of concerns.
>
> So I guess we can agree on sorting fields alphabetically.
>
> Let's get to the initial question:
> * Should we do the sorting for the user (performance hit)?
> * Should we at least validate user-defined order?
>
> On Wed, Apr 12, 2017 at 2:12 AM, Dmitriy Setrakyan 
> wrote:
>
> > On Tue, Apr 11, 2017 at 1:28 PM, Sergi Vladykin <
> sergi.vlady...@gmail.com>
> > wrote:
> >
> > > I'm just trying to understand the current state of things and risks.
> May
> > be
> > > we need to do some adjustments here before 2.0 to be on the safe side.
> > >
> > > Actually looks like this not really important, we just have to clearly
> > > document that DML builds keys this way and require from user to do the
> > same
> > > to be able to use cache API.
> > >
> >
> >
> > I think it is important from the usability stand point. A user can always
> > sort fields alphabetically in his or her mind. However, trying to
> remember
> > the field order from some QueryEntity is a lot harder.
> >
>

Re: Sorting fields of Binarilyzable objects on write

[Pavel Tupitsyn]

QueryEntity order is not only harder for the users, it will be nightmare to
implement.
What if there is no QueryEntity defined? What if the same class is used in
multiple QueryEntity?
I don't think serialization code has to be tied to QueryEntity in any way,
this violates separation of concerns.

So I guess we can agree on sorting fields alphabetically.

Let's get to the initial question:
* Should we do the sorting for the user (performance hit)?
* Should we at least validate user-defined order?

On Wed, Apr 12, 2017 at 2:12 AM, Dmitriy Setrakyan 
wrote:

> On Tue, Apr 11, 2017 at 1:28 PM, Sergi Vladykin 
> wrote:
>
> > I'm just trying to understand the current state of things and risks. May
> be
> > we need to do some adjustments here before 2.0 to be on the safe side.
> >
> > Actually looks like this not really important, we just have to clearly
> > document that DML builds keys this way and require from user to do the
> same
> > to be able to use cache API.
> >
>
>
> I think it is important from the usability stand point. A user can always
> sort fields alphabetically in his or her mind. However, trying to remember
> the field order from some QueryEntity is a lot harder.
>