Re: Changing cache name when using Redis protocol

Yakov, Thanks for sharing your thoughts! I agree that both configuration and CONFIG SET lack flexibility. Let’s forget about these approaches. For specifying cache per connection, CLIENT SETNAME [cache_name] [1] can be another option. It can be done with config templates as you proposed too.

Re: IGNITE-4447 ready for review

Hi guys! Semyon, test suite Ignite Cache 5 with Cache150ClientsTest failed. Run it twice. But local it succesfully executed. What do you think about it ? http://ci.ignite.apache.org/viewLog.html?buildId=616787=buildResultsDiv=IgniteTests_IgniteCache5 Vadim 2017-05-17 11:34 GMT+03:00 Вадим

Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)

Cos, Roman, This has nothing to do with any deadlines, but rather with an easier and more efficient process. I am not sure how keeping the code in a separate code base is better for the community than keeping it in a separate Apache Ignite branch, where we can integrate it into Ignite CI

Re: A feedback on WebConsole

Thanks Denis! Always nice to hear that our community is growing :) On Thu, May 18, 2017 at 5:40 PM, Denis Magda wrote: > Had a pleasure to present Ignite at ApacheCon. In addition to the positive > feedback I received at the show here is the one spotted in twitter: >

A feedback on WebConsole

Had a pleasure to present Ignite at ApacheCon. In addition to the positive feedback I received at the show here is the one spotted in twitter: https://twitter.com/ardlema/status/865214808731373569 — Denis

Re: SqlFields query result does not expose fields metadata.

Proposal is about returning GridQueryFieldMetadata from QueryCursor, which is internal interface. This interface is counterintuitive and is not ready to be exposed to users. For example, it has method "typeName" which actually returns table name. And has method "fieldTypeName" which returns

[GitHub] ignite pull request #1972: ignore. PR for test on TC(IGNITE-5227)

GitHub user mcherkasov opened a pull request: https://github.com/apache/ignite/pull/1972 ignore. PR for test on TC(IGNITE-5227) ignore. PR for test on TC(IGNITE-5227) You can merge this pull request into a Git repository by running: $ git pull

Re: waiting for partition release question

Done! 2017-05-18 20:33 GMT+03:00 Denis Magda : > Alex, > > Can you add this excellent explanation as a part of the method Javadoc? > That will simplify a lot the life of future contributors. > > — > Denis > > > On May 18, 2017, at 1:05 PM, Alexey Goncharuk < >

Re: waiting for partition release question

Alex, Can you add this excellent explanation as a part of the method Javadoc? That will simplify a lot the life of future contributors. — Denis > On May 18, 2017, at 1:05 PM, Alexey Goncharuk > wrote: > > Hi Aleksey, > > The main purpose of this method is to

Re: waiting for partition release question

Hi Aleksey, The main purpose of this method is to wait for all ongoing updates (transactional and atomic), initiated on the previous topology version, to finish to prevent inconsistencies during rebalancing and to prevent two different simultaneous owners of the same lock. We will be adding

[GitHub] ignite pull request #1970: Ignite 5203

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

[GitHub] ignite pull request #1970: Ignite 5203

GitHub user agura opened a pull request: https://github.com/apache/ignite/pull/1970 Ignite 5203 You can merge this pull request into a Git repository by running: $ git pull https://github.com/agura/incubator-ignite ignite-5203 Alternatively you can review and apply these

Re: SqlFields query result does not expose fields metadata.

It should not require any internals movement, it must be an easy fix. Sergi 2017-05-18 15:36 GMT+03:00 Vladimir Ozerov : > With all the changes to internals we made, new API can be created very > quickly somewhere around AI 2.2 or AI 2.3. Currently the whole API is >

[GitHub] ignite pull request #1969: Ignite 5259 Support backward compatibility with v...

GitHub user dkarachentsev opened a pull request: https://github.com/apache/ignite/pull/1969 Ignite 5259 Support backward compatibility with versions without service permissions You can merge this pull request into a Git repository by running: $ git pull

[jira] [Created] (IGNITE-5259) Support backward compatibility with versions without service permissions

Dmitry Karachentsev created IGNITE-5259: --- Summary: Support backward compatibility with versions without service permissions Key: IGNITE-5259 URL: https://issues.apache.org/jira/browse/IGNITE-5259

[jira] [Created] (IGNITE-5258) CPP: It should be possible to set timeout for SQL query in C++

Igor Sapego created IGNITE-5258: --- Summary: CPP: It should be possible to set timeout for SQL query in C++ Key: IGNITE-5258 URL: https://issues.apache.org/jira/browse/IGNITE-5258 Project: Ignite

[jira] [Created] (IGNITE-5257) .NET: SQL query timeouts

Pavel Tupitsyn created IGNITE-5257: -- Summary: .NET: SQL query timeouts Key: IGNITE-5257 URL: https://issues.apache.org/jira/browse/IGNITE-5257 Project: Ignite Issue Type: Improvement

waiting for partition release question

Hi Igntrs! What is the point of waiting partition release in the end of GridDhtPartitionsExchangeFuture#init() method ? In what scenarious do we need it ? -- *Best Regards,* *Kuznetsov Aleksey*

Re: Get Started. VitaliyB

Hello Vitaliy, Welcome to the Ignite community! Added you to the contributors list in JIRA. Now you can assign the ticket on yourself. Please subscribe to both dev and user lists if you haven’t done this yet: https://ignite.apache.org/community/resources.html#mail-lists Get familiar with

Re: Problem with indexing LocalDate in Ignite 2.0

Cross posting to the dev list. Vovan, Sergi, were there any changes related to java.time.LocalDate usage at the level of binary marshaller or SQL engine? I can’t find any mentioning of this in the migration guide [1] which makes me thinking that this is a 2.0 bug. [1]

Re: IGNITE - 3469

As far as I see, we could remove a lot of deprecated classes and properties. The rest can be done in 3.0 time frame. Alex G., don’t you mind if we close the ticket? Otherwise, it will be shifted from one release to another until we approach 3.0. — Denis > On May 18, 2017, at 7:30 AM, Вадим

Re: SqlFields query result does not expose fields metadata.

With all the changes to internals we made, new API can be created very quickly somewhere around AI 2.2 or AI 2.3. Currently the whole API is located in the wrong place, as it is bounded to cache. So the more we add now, the more we will deprecate in several months. Remember, that this feature will

Re: SqlFields query result does not expose fields metadata.

I agree that this change makes sense. With complex queries it may be non-trivial to get the right column by index from results. With metadata user no longer needs to care about result column order, and refactorings are easier. Pavel On Thu, May 18, 2017 at 2:36 PM, Sergi Vladykin

Re: Changing cache name when using Redis protocol

Roman, I don't like implementing of special configuration type - you loose flexibility in this case, e.g. adding cache will most likely be a pain or a complete restart. CONFIG SET may work, but for redis this is some kind of global configuration, so it is pretty far from, let's say, MySQL's USE

Re: SqlFields query result does not expose fields metadata.

I believe we will not see this new SQL API soon. It is not even in design stage. The change proposed by Andrey is very simple and our users will benefit from it right away. I see no reasons to disallow this change. Sergi 2017-05-18 12:35 GMT+03:00 Vladimir Ozerov : >

IGNITE - 3469

Hi guys! Is issue https://issues.apache.org/jira/browse/IGNITE-3469 actual now ? What else needs to be done ? Vadim

[GitHub] ignite pull request #1968: Ignite 4575 binary enum for test purposes

GitHub user skalashnikov opened a pull request: https://github.com/apache/ignite/pull/1968 Ignite 4575 binary enum for test purposes You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-4575-binary

[jira] [Created] (IGNITE-5256) Improve HTTP (REST) documentation

Pavel Tupitsyn created IGNITE-5256: -- Summary: Improve HTTP (REST) documentation Key: IGNITE-5256 URL: https://issues.apache.org/jira/browse/IGNITE-5256 Project: Ignite Issue Type: Task

[jira] [Created] (IGNITE-5255) JDBC Driver: support DML

Taras Ledkov created IGNITE-5255: Summary: JDBC Driver: support DML Key: IGNITE-5255 URL: https://issues.apache.org/jira/browse/IGNITE-5255 Project: Ignite Issue Type: Task

SqlFields query result does not expose fields metadata.

Hi Igniters, When user run Sql query via JDBC, he can get fields metadata (field names, its types and etc.) from ResultSet. With IgniteCache.query method he gets some QueryCursor implementation, but QueryCursor interface doesn't have any methods for this. For now, the only way to get metadata is

[jira] [Created] (IGNITE-5254) Add web-console folder structure description

Dmitriy Shabalin created IGNITE-5254: Summary: Add web-console folder structure description Key: IGNITE-5254 URL: https://issues.apache.org/jira/browse/IGNITE-5254 Project: Ignite Issue

[jira] [Created] (IGNITE-5253) .NET: Fields query cursor metadata

Pavel Tupitsyn created IGNITE-5253: -- Summary: .NET: Fields query cursor metadata Key: IGNITE-5253 URL: https://issues.apache.org/jira/browse/IGNITE-5253 Project: Ignite Issue Type:

[jira] [Created] (IGNITE-5252) SqlFieldsQuery result set should expose fields metadata.

Andrew Mashenkov created IGNITE-5252: Summary: SqlFieldsQuery result set should expose fields metadata. Key: IGNITE-5252 URL: https://issues.apache.org/jira/browse/IGNITE-5252 Project: Ignite

Get Started. VitaliyB

Hello, Igniters! I want to start contributing to Ignite. And to start take this ticket - IGNITE-4181. My JIRA ID – VitaliyB. Best Regards, Vitaliy Biryukov

Re: SQL usability issue: unclear exception when a key of a wrong type is used

Denis, good point, I have also seen this confusing error a number of times. And even if there is a clear description of an error, it is buried deep into the "caused by". For example, if I misprint a table name, this is what I get: class IgniteCheckedException: Failed to parse query: ... Caused

[jira] [Created] (IGNITE-5251) Some JVM implementations may return null from getClassLoader()

Alexandr Kuramshin created IGNITE-5251: -- Summary: Some JVM implementations may return null from getClassLoader() Key: IGNITE-5251 URL: https://issues.apache.org/jira/browse/IGNITE-5251 Project:

Re: SQL usability issue: unclear exception when a key of a wrong type is used

Vova, Sergi, Any chance we can provide a proper error message in the exception? D. On Wed, May 17, 2017 at 8:50 PM, Denis Magda wrote: > Sergi, Vovan, > > One of Ignite users struggled with an SQL issue and asked me to help him > troubleshooting it. The root of the issue