[GitHub] ignite pull request: ignite-2218: deleted HadoopNativeCodeLoader

GitHub user iveselovskiy opened a pull request: https://github.com/apache/ignite/pull/361 ignite-2218: deleted HadoopNativeCodeLoader You can merge this pull request into a Git repository by running: $ git pull https://github.com/iveselovskiy/ignite ignite-2218 Alternatively

[jira] [Created] (IGNITE-2221) CPP: Need to implement Decimal data type support for binary protocol.

Igor Sapego created IGNITE-2221: --- Summary: CPP: Need to implement Decimal data type support for binary protocol. Key: IGNITE-2221 URL: https://issues.apache.org/jira/browse/IGNITE-2221 Project: Ignite

Re: Missing ways to get access to Ignite CacheEntry

Andrey, I think getEntry(…) can be done quickly. Adding another serialization mechanism for cache entries together with a configuration flag may take additional time. I would suggest, again, starting with getEntry method and then moving down to queries. D. On Mon, Dec 21, 2015 at 1:04 PM,

Re: Missing ways to get access to Ignite CacheEntry

Here is the ticket: https://issues.apache.org/jira/browse/IGNITE-2224 On Mon, Dec 21, 2015 at 3:57 PM, Andrey Kornev wrote: > Ok, deal! And while we're at it could we add getAllEntries(Set) as per > Denis suggestion? > > Thanks > Andrey > > > From:

[jira] [Created] (IGNITE-2223) CPP: ODBC queries sometimes return wrong types for columns in metadata.

Igor Sapego created IGNITE-2223: --- Summary: CPP: ODBC queries sometimes return wrong types for columns in metadata. Key: IGNITE-2223 URL: https://issues.apache.org/jira/browse/IGNITE-2223 Project:

[jira] [Created] (IGNITE-2222) CPP: Implement Date type support for binary protocol.

Igor Sapego created IGNITE-: --- Summary: CPP: Implement Date type support for binary protocol. Key: IGNITE- URL: https://issues.apache.org/jira/browse/IGNITE- Project: Ignite Issue

Re: Missing ways to get access to Ignite CacheEntry

On 12/21/2015 11:15 AM, Dmitriy Setrakyan wrote: On Mon, Dec 21, 2015 at 12:11 AM, Denis Magda wrote: Why it shouldn't work? If client receives an entry that has a reference to the entry with version, transferred from a server as well as a part of the response, then

Re: Adding tests suites for new streamers on TeamCity

Who would have enough permissions to do this? On Sun, Dec 20, 2015 at 5:17 PM, Roman Shtykh wrote: > Igniters, > > How about adding the following test suites to "Ignite Streamers" on > TeamCity > > org.apache.ignite.stream.flume.IgniteSinkTestSuite >

Re: Adding tests suites for new streamers on TeamCity

Done. Roman, thanks for pointing out to this. On 12/21/2015 11:36 AM, Dmitriy Setrakyan wrote: Who would have enough permissions to do this? On Sun, Dec 20, 2015 at 5:17 PM, Roman Shtykh wrote: Igniters, How about adding the following test suites to "Ignite

Re: Missing ways to get access to Ignite CacheEntry

On Mon, Dec 21, 2015 at 12:11 AM, Denis Magda wrote: > Why it shouldn't work? > If client receives an entry that has a reference to the entry with > version, transferred from a server as well as a part of the response, then > unwrap(...) should work. > Isn't this feasible to

Re: CacheEntry serialization failure

Folks, I thought about the solution a bit more and came to the following design. *Scenario:* class A { int x; } class B : extends A { int y; } *Solution:* 1) Field A.x is written as *"A.x"*, field B.x is written as *"B.x"*. I.e. *both conflicting fields are prefixed* with simple name of

[jira] [Created] (IGNITE-2215) .NET: Replace collection factory/adder in BinaryReader with Func/Action

Pavel Tupitsyn created IGNITE-2215: -- Summary: .NET: Replace collection factory/adder in BinaryReader with Func/Action Key: IGNITE-2215 URL: https://issues.apache.org/jira/browse/IGNITE-2215 Project:

[jira] [Created] (IGNITE-2218) Ignite nodes cannot run Hadoop native code (e.g. snappy)

Ivan Veselovsky created IGNITE-2218: --- Summary: Ignite nodes cannot run Hadoop native code (e.g. snappy) Key: IGNITE-2218 URL: https://issues.apache.org/jira/browse/IGNITE-2218 Project: Ignite

Re: CacheEntry serialization failure

Are you talking about SQL queries? I thought that we agreed to use field aliases in case of name conflicts, no? D. > On Dec 21, 2015, at 4:57 AM, Vladimir Ozerov wrote: > > Several additional problems appeared: > 1) We must use fully-qualified class names because simple

[GitHub] ignite pull request: Ignite 2206

Github user iveselovskiy closed the pull request at: https://github.com/apache/ignite/pull/359 --- 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

[GitHub] ignite pull request: 2206

GitHub user iveselovskiy opened a pull request: https://github.com/apache/ignite/pull/360 2206 You can merge this pull request into a Git repository by running: $ git pull https://github.com/iveselovskiy/ignite ignite-2206 Alternatively you can review and apply these changes

Re: 1.5.final

Regarding IGNITE-2212. The original issue is reproduced only with optimized marshaller, so I don't think it's critical. But at the same time I observe strange behavior when I run the same test with binary marshaller: to send an Externalizable object across network, we serialize, deserialize, and

[jira] [Created] (IGNITE-2226) Replace dash in 1.5.0-final with dot 1.5.0.final

Dmitriy Setrakyan created IGNITE-2226: - Summary: Replace dash in 1.5.0-final with dot 1.5.0.final Key: IGNITE-2226 URL: https://issues.apache.org/jira/browse/IGNITE-2226 Project: Ignite

UNRESOLVED tickets

Raul, Cos, You have 9 tickets in RESOLVED state for 1.5 release. Can these tickets be closed or is there some work left? If these tickets can be closed, can I ask you to close these tickets? Here is a link to the RESOLVED tickets: http://s.apache.org/1.5-resolved D.

Re: 1.5.final

Valentin, great catch! You should add this test to the cache suite and make sure it fails, so we will be certain to fix it before the final release. Let’s also file a blocker ticket for it. Moreover, we should have an identical test for non-externalizable classes, however I am not sure yet how to

Re: 1.5.final

As per my I tickets, I have only single task targeting 1.5 - https://issues.apache.org/jira/browse/IGNITE-2209 Hope it will be finished in the nearest time. As per Externalizable issue, this could be due to my latests changes to serialization logic. For now both Externalizables and objects with

Re: 1.5.final

Sorry, I meant *IGNITE-2213*, not IGNITE-2209. On Tue, Dec 22, 2015 at 9:00 AM, Vladimir Ozerov wrote: > As per my I tickets, I have only single task targeting 1.5 - > https://issues.apache.org/jira/browse/IGNITE-2209 Hope it will be > finished in the nearest time. > > As

[jira] [Created] (IGNITE-2225) Externalizable classes are serialized twice with binary marshaller

Valentin Kulichenko created IGNITE-2225: --- Summary: Externalizable classes are serialized twice with binary marshaller Key: IGNITE-2225 URL: https://issues.apache.org/jira/browse/IGNITE-2225

Re: 1.5.final

Here is the ticket for this issue: https://issues.apache.org/jira/browse/IGNITE-2225 On Mon, Dec 21, 2015 at 10:00 PM, Vladimir Ozerov wrote: > As per my I tickets, I have only single task targeting 1.5 - > https://issues.apache.org/jira/browse/IGNITE-2209 Hope it will be

Re: Versioning policies for .NET and CPP

Ideally, text suffixes in the versions shouldn't be used _anywhere_. I think this umpteenth time I am saying this, but why we are so married to the 'b', 'p', 'r', and 'f' (whatever the last one stands for)? semver is using 4th numerical position for patch-level, and it only denominates the

Re: UNRESOLVED tickets

On Mon, Dec 21, 2015 at 10:26PM, Dmitriy Setrakyan wrote: > Raul, Cos, > > You have 9 tickets in RESOLVED state for 1.5 release. Can these tickets be > closed or is there some work left? Elseprojects resolved effectively means closed for the simplicity of the workflow. I marked mine as closed.

Re: 1.5.final

1.5.final is bigger that 1.5.0-b1? Or lesser? On Mon, Dec 21, 2015 at 08:33AM, Dmitriy Setrakyan wrote: > I would like to assemble a list of the remaining issues for the 1.5 final > release. Can everyone in the community please reply here with a list of > tickets you are still working on for 1.5

Re: 1.5 GA

Well, being too close to the release doesn't mean that we need to rush and produce yet another one that will be causing troubles downstream. There's nothing to research really. Just dump the string suffixes in the versions and be happy. They are solving nothing, but create confusion and

Re: 1.5.final

>From maven standpoint, 1.5.0.final comes after 1.5.0-b1. Can someone double confirm this? D. On Mon, Dec 21, 2015 at 10:34 PM, Konstantin Boudnik wrote: > 1.5.final is bigger that 1.5.0-b1? Or lesser? > > On Mon, Dec 21, 2015 at 08:33AM, Dmitriy Setrakyan wrote: > > I would

Re: Missing ways to get access to Ignite CacheEntry

Again, my issue is with unwrap method. Are we all in agreement that unwrap(…) will not work on the client side? D. On Sun, Dec 20, 2015 at 11:30 PM, Denis Magda wrote: > Actually I think that Andrey's proposal on addition of > IgniteCache.getEntry(k) sounds natural. > > Is

Re: Missing ways to get access to Ignite CacheEntry

Why it shouldn't work? If client receives an entry that has a reference to the entry with version, transferred from a server as well as a part of the response, then unwrap(...) should work. Isn't this feasible to implement? -- Denis On 12/21/2015 10:59 AM, Dmitriy Setrakyan wrote: Again, my

[jira] [Created] (IGNITE-2214) Incorrect java-code for near configuration

Pavel Konstantinov created IGNITE-2214: -- Summary: Incorrect java-code for near configuration Key: IGNITE-2214 URL: https://issues.apache.org/jira/browse/IGNITE-2214 Project: Ignite

Re: CacheEntry serialization failure

Denis, Yes, as we do not know which field to pick, we return null. On Mon, Dec 21, 2015 at 12:00 PM, Denis Magda wrote: > Sounds good for me. I would go for this approach. > > In addition if to consider your example below and the user decides to look > up a field by its

Re: CacheEntry serialization failure

Sounds good for me. I would go for this approach. In addition if to consider your example below and the user decides to look up a field by its simple name then he/she will get nothing or exception (depending on the API), correct? As an example for this case the method will return null

[GitHub] ignite pull request: IGNITE-2215 .NET: Replace collection factory/...

GitHub user ptupitsyn opened a pull request: https://github.com/apache/ignite/pull/358 IGNITE-2215 .NET: Replace collection factory/adder in BinaryReader with Func/Action …th Func/Action You can merge this pull request into a Git repository by running: $ git pull

Re: CacheEntry serialization failure

Agree, prefixing parent class fields sound like a better option. Regarding aliases - I need some time to understand internal mechanics. Will answer this a bit later. On Mon, Dec 21, 2015 at 11:18 AM, Dmitriy Setrakyan wrote: > Vova, > > Shouldn’t it be the other way

Re: CacheEntry serialization failure

Vova, We cannot return null in case of a conflict, as user won’t be able to differentiate between a conflict and missing field. We should throw an exception. Also, I don’t like parsing field names looking for a dot for every field. It will introduce a performance overhead for the cases that do

Re: CacheEntry serialization failure

Dima, Here is how proposed design works: class A { int x = 1; } class B { int x = 2; } BinaryObject obj = ...; Object val = obj.field("A.x"); // Returns "1"; Object val = obj.field("B.x"); // Returns "2"; Object val = obj.field("x"); // Returns null; boolean exists =

Re: CacheEntry serialization failure

Dima, No sure what example did you mean. I was talking about QuerySqlField(name=[alias]) set on field. However, sometimes user will not be able to set annotations on fields because he cannot change class. QueryEntity.aliases can help is in these cases I think. On Mon, Dec 21, 2015 at 7:23 PM,

[jira] [Created] (IGNITE-2228) .NET: Ensure async Task can be cancelled.

Vladimir Ozerov created IGNITE-2228: --- Summary: .NET: Ensure async Task can be cancelled. Key: IGNITE-2228 URL: https://issues.apache.org/jira/browse/IGNITE-2228 Project: Ignite Issue Type:

Re: CacheEntry serialization failure

Fully agree. QueryEntity should support the same configuration as QuerySqlField annotation. Isn’t that the case now? On Mon, Dec 21, 2015 at 10:07 PM, Vladimir Ozerov wrote: > Dima, > > No sure what example did you mean. I was talking about > QuerySqlField(name=[alias])

Re: 1.5 GA

I filed the ticket: https://issues.apache.org/jira/browse/IGNITE-2226 I think we should change dash to dot for now. Anton, can you explain why this is a big change? D. On Mon, Dec 21, 2015 at 10:28 PM, Konstantin Boudnik wrote: > Well, being too close to the release doesn't

Re: UNRESOLVED tickets

Thanks Cos! Raul, all remaining Resolved tickets are assigned to you. Can you please either close them or comment them? Thanks, D. On Mon, Dec 21, 2015 at 10:33 PM, Konstantin Boudnik wrote: > On Mon, Dec 21, 2015 at 10:26PM, Dmitriy Setrakyan wrote: > > Raul, Cos, > > > >

[jira] [Created] (IGNITE-2227) Please add support of cache alias on web console

Pavel Konstantinov created IGNITE-2227: -- Summary: Please add support of cache alias on web console Key: IGNITE-2227 URL: https://issues.apache.org/jira/browse/IGNITE-2227 Project: Ignite

[jira] [Created] (IGNITE-2216) Duplicate field names with aliases do not work in queries.

Vladimir Ozerov created IGNITE-2216: --- Summary: Duplicate field names with aliases do not work in queries. Key: IGNITE-2216 URL: https://issues.apache.org/jira/browse/IGNITE-2216 Project: Ignite

[jira] [Created] (IGNITE-2217) Add BinaryConfiguration support to cluster screen

Alexey Kuznetsov created IGNITE-2217: Summary: Add BinaryConfiguration support to cluster screen Key: IGNITE-2217 URL: https://issues.apache.org/jira/browse/IGNITE-2217 Project: Ignite

Re: Missing ways to get access to Ignite CacheEntry

On Mon, Dec 21, 2015 at 12:36 AM, Denis Magda wrote: > > > On 12/21/2015 11:15 AM, Dmitriy Setrakyan wrote: > >> On Mon, Dec 21, 2015 at 12:11 AM, Denis Magda >> wrote: >> >> Why it shouldn't work? >>> If client receives an entry that has a reference to

1.5.final

I would like to assemble a list of the remaining issues for the 1.5 final release. Can everyone in the community please reply here with a list of tickets you are still working on for 1.5 release? Thanks, D.

Re: 1.5.final

Status for the opened tickets from my side: https://issues.apache.org/jira/browse/IGNITE-2078The original issue reported has been fixed. Now sometimes the example returns duplicate records for TXT queries, this is related to changing topology not being handled in TXT queries. This is an old issue

[jira] [Created] (IGNITE-2219) ClassCastException from NodeIdMessage to AffinityTopologyVersion

Avihai Berkovitz created IGNITE-2219: Summary: ClassCastException from NodeIdMessage to AffinityTopologyVersion Key: IGNITE-2219 URL: https://issues.apache.org/jira/browse/IGNITE-2219 Project:

Re: Adding tests suites for new streamers on TeamCity

Thank you, Denis. On Mon, 12/21/15, Denis Magda wrote: Subject: Re: Adding tests suites for new streamers on TeamCity To: dev@ignite.apache.org Date: Monday, December 21, 2015, 8:05 PM Done. Roman, thanks for pointing

Re: 1.5.final

Alexey, About IGNITE-2212 - can you explain why the value is deserialized at all, even once, let alone multiple times? D. On Mon, Dec 21, 2015 at 8:57 AM, Alexey Goncharuk < alexey.goncha...@gmail.com> wrote: > Status for the opened tickets from my side: > >

[jira] [Created] (IGNITE-2220) upgrade gulp tasks

Dmitriyff created IGNITE-2220: - Summary: upgrade gulp tasks Key: IGNITE-2220 URL: https://issues.apache.org/jira/browse/IGNITE-2220 Project: Ignite Issue Type: Sub-task Affects Versions: 1.6