Re: Enums and SQL queries

GridQueryProcessor contains two types: BinaryProperty and ClassProperty. Indexing uses them for fields access. Probably we can change them, so that they will always return String instead of Enum type but this 1. looks like a compatibility breaking change; 2. users doing queries like `select

Re: "ArrayIndexOutOfBoundsException" happened when doing qurey in version 1.6.0

We already have similar issue reproduced in our benchmarks - https://issues.apache.org/jira/browse/IGNITE-3300. I think this is related to optimziation done in 1.6 to store key partition in the cache key. I believe fix will be included in 1.7 release. On Tue, Jul 26, 2016 at 2:13 AM, Valentin

[GitHub] ignite pull request #889: ignite-3563 Support distributedJoins flag in JDBC ...

Github user agura closed the pull request at: https://github.com/apache/ignite/pull/889 --- 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 #891: ignite-3573 Support of Distributed joins queries i...

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

Re: Data compression in Ignite 2.0

I'm guessing the suggestion here is to use the compressed form directly for WHERE clause evaluation. If that's the case I think there are a couple of issues: 1) the LIKE predicate. 2) predicates other than equality (for example, <, >, etc.) But since Ignite isn't just about SQL queries

Re: Enums and SQL queries

Sergi, Ideally, I would like this query to work: select * from MyTable where myEnumField = 'MY_ENUM_NAME' The problem is that the field value is not a string, it's a binary object with the enum value ordinal inside. We can add enum value names into the metadata, so that we can always map the

Re: "ArrayIndexOutOfBoundsException" happened when doing qurey in version 1.6.0

Crossposting to dev@ Folks, I noticed the exception below in couple of user threads already. This actually means that partition number for the key is -1, which doesn't make much sense to me. Does anyone has any ideas? Caused by: java.lang.ArrayIndexOutOfBoundsException: -1 at

Re: Implement collecting what SQL statements executed on cluster and their metrics.

SET query is for IgniteSet and it's internal only, not exposed to the public API. -Val On Mon, Jul 25, 2016 at 3:37 PM, Dmitriy Setrakyan wrote: > My comments are below... > > On Thu, Jul 7, 2016 at 9:41 AM, Alexey Kuznetsov > wrote: > > > Hi,

[GitHub] ignite pull request #895: IGNITE-3323 Use maven dependencies for Jetbrains a...

GitHub user jayho opened a pull request: https://github.com/apache/ignite/pull/895 IGNITE-3323 Use maven dependencies for Jetbrains annotations You can merge this pull request into a Git repository by running: $ git pull https://github.com/jayho/ignite ignite-3323

Re: Implement collecting what SQL statements executed on cluster and their metrics.

My comments are below... On Thu, Jul 7, 2016 at 9:41 AM, Alexey Kuznetsov wrote: > Hi, All! > > I'm working on issue "Implement collecting what SQL statements executed on > cluster and their metrics" [1] > > For now I'm investigating code and have following questions: >

Re: Data compression in Ignite 2.0

Nikita, this sounds like a pretty elegant approach. Does anyone in the community see a problem with this design? On Mon, Jul 25, 2016 at 4:49 PM, Nikita Ivanov wrote: > SAP Hana does the compression by 1) compressing SQL parameters before > execution, and 2) storing only

Re: Data compression in Ignite 2.0

SAP Hana does the compression by 1) compressing SQL parameters before execution, and 2) storing only compressed data in memory. This way all SQL queries work as normal with zero modifications or performance overhead. Only results of the query can be (optionally) decompressed back before returning

Re: Data compression in Ignite 2.0

Hi For approach 1: Put a large object into a partiton cache will force to update the dictionary placed on replication cache. It seeis it may be time-expense operation. Appoach 2-3 are make sense for rare cases as Sergi commented. Aslo I see a danger of OOM if we've got high compression level and

[GitHub] ignite pull request #894: IGNITE-3578: Added support of DistributedJoins to ...

GitHub user isapego opened a pull request: https://github.com/apache/ignite/pull/894 IGNITE-3578: Added support of DistributedJoins to SqlQuery and SqlFieldsQuery. You can merge this pull request into a Git repository by running: $ git pull https://github.com/isapego/ignite

Re: Distributed joins for JDBC

Added properties to .NET (https://issues.apache.org/jira/browse/IGNITE-3561 ). On Mon, Jul 25, 2016 at 1:23 PM, Andrey Gura wrote: > Implemented. See corresponding ticket. > > Not supported by Java client based driver because it is deprecated and does > not support any

[GitHub] ignite pull request #893: IGNITE-3561 .NET: DistributedJoins property in Sql...

Github user ptupitsyn closed the pull request at: https://github.com/apache/ignite/pull/893 --- 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 #893: IGNITE-3561 .NET: DistributedJoins property in Sql...

GitHub user ptupitsyn opened a pull request: https://github.com/apache/ignite/pull/893 IGNITE-3561 .NET: DistributedJoins property in SqlQuery & SqlFieldsQuery You can merge this pull request into a Git repository by running: $ git pull https://github.com/ptupitsyn/ignite

[GitHub] ignite pull request #892: IGNITE-3504 .NET: Fix IBinaryObjectBuilder setter ...

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

[jira] [Created] (IGNITE-3577) ODBC: Replace "Server" and "Port" connection string arguments with single argument "Address"

Igor Sapego created IGNITE-3577: --- Summary: ODBC: Replace "Server" and "Port" connection string arguments with single argument "Address" Key: IGNITE-3577 URL: https://issues.apache.org/jira/browse/IGNITE-3577

[GitHub] ignite pull request #892: IGNITE-3504 .NET: Fix IBinaryObjectBuilder setter ...

GitHub user ptupitsyn opened a pull request: https://github.com/apache/ignite/pull/892 IGNITE-3504 .NET: Fix IBinaryObjectBuilder setter methods You can merge this pull request into a Git repository by running: $ git pull https://github.com/ptupitsyn/ignite ignite-3504

[GitHub] ignite pull request #891: ignite-3573 Support of Distributed joins queries i...

GitHub user agura opened a pull request: https://github.com/apache/ignite/pull/891 ignite-3573 Support of Distributed joins queries in REST API You can merge this pull request into a Git repository by running: $ git pull https://github.com/agura/incubator-ignite ignite-3573

[jira] [Created] (IGNITE-3576) .NET: Implement distributed data structures.

Vladimir Ozerov created IGNITE-3576: --- Summary: .NET: Implement distributed data structures. Key: IGNITE-3576 URL: https://issues.apache.org/jira/browse/IGNITE-3576 Project: Ignite Issue

[jira] [Created] (IGNITE-3575) CPP: Support continuous queries remote filters.

Vladimir Ozerov created IGNITE-3575: --- Summary: CPP: Support continuous queries remote filters. Key: IGNITE-3575 URL: https://issues.apache.org/jira/browse/IGNITE-3575 Project: Ignite Issue

[jira] [Created] (IGNITE-3574) CPP: Implement compute API

Vladimir Ozerov created IGNITE-3574: --- Summary: CPP: Implement compute API Key: IGNITE-3574 URL: https://issues.apache.org/jira/browse/IGNITE-3574 Project: Ignite Issue Type: Task

[jira] [Created] (IGNITE-3572) CPP: Improve binary marshaller capabilities.

Vladimir Ozerov created IGNITE-3572: --- Summary: CPP: Improve binary marshaller capabilities. Key: IGNITE-3572 URL: https://issues.apache.org/jira/browse/IGNITE-3572 Project: Ignite Issue

[jira] [Created] (IGNITE-3571) CPP: Improve Cache API.

Vladimir Ozerov created IGNITE-3571: --- Summary: CPP: Improve Cache API. Key: IGNITE-3571 URL: https://issues.apache.org/jira/browse/IGNITE-3571 Project: Ignite Issue Type: Task

[GitHub] ignite pull request #890: IGNITE-3569 - Set copyOnRead property to FALSE for...

GitHub user dkarachentsev opened a pull request: https://github.com/apache/ignite/pull/890 IGNITE-3569 - Set copyOnRead property to FALSE for marshaller cache You can merge this pull request into a Git repository by running: $ git pull

[GitHub] ignite pull request #889: ignite-3563 Support distributedJoins flag in JDBC ...

GitHub user agura opened a pull request: https://github.com/apache/ignite/pull/889 ignite-3563 Support distributedJoins flag in JDBC driver You can merge this pull request into a Git repository by running: $ git pull https://github.com/agura/incubator-ignite ignite-3563

[jira] [Created] (IGNITE-3569) Set copyOnRead property to FALSE for marshaller cache

Yakov Zhdanov created IGNITE-3569: - Summary: Set copyOnRead property to FALSE for marshaller cache Key: IGNITE-3569 URL: https://issues.apache.org/jira/browse/IGNITE-3569 Project: Ignite

Re: Implement collecting what SQL statements executed on cluster and their metrics.

Hi All! Just kindly remind for feedback. Thanks! On Thu, Jul 7, 2016 at 8:41 PM, Alexey Kuznetsov wrote: > Hi, All! > > I'm working on issue "Implement collecting what SQL statements executed on > cluster and their metrics" [1] > > For now I'm investigating code and

[jira] [Created] (IGNITE-3567) .NET: AppFabric integration.

Vladimir Ozerov created IGNITE-3567: --- Summary: .NET: AppFabric integration. Key: IGNITE-3567 URL: https://issues.apache.org/jira/browse/IGNITE-3567 Project: Ignite Issue Type: Task

[jira] [Created] (IGNITE-3566) .NET: Memcached integration.

Vladimir Ozerov created IGNITE-3566: --- Summary: .NET: Memcached integration. Key: IGNITE-3566 URL: https://issues.apache.org/jira/browse/IGNITE-3566 Project: Ignite Issue Type: Task

Re: Distributed joins for JDBC

Pavel, There are two reasons for this: 1. This setting may affect performance for all the cases you mentioned, because it does much more complex query optimization. 2. This feature is quite new and I want to release it in the safest possible way because we may just brake existing applications if

Re: Distributed joins for JDBC

Why we need to *TURN ON/OFF* this mode? Why not have it always *ON*? On Mon, Jul 25, 2016 at 2:32 PM, Andrey Gura wrote: > Our JDBC drivers already have connection properties that correspond to > SqlFieldsQuery properties. So we can just add support of this parameter to >

Re: Data compression in Ignite 2.0

Sergi, Of course it will introduce some slowdown, but with compression more data could be stored in memory and not will be evicted to disk. In case of compress by dictionary substitution it will be only one more lookup and should be fast. In general we could provide only API for compression out

[jira] [Created] (IGNITE-3565) .NET: ASP.NET view stat cache

Vladimir Ozerov created IGNITE-3565: --- Summary: .NET: ASP.NET view stat cache Key: IGNITE-3565 URL: https://issues.apache.org/jira/browse/IGNITE-3565 Project: Ignite Issue Type: Sub-task

[jira] [Created] (IGNITE-3564) .NET: Integrate with ASP.NET

Vladimir Ozerov created IGNITE-3564: --- Summary: .NET: Integrate with ASP.NET Key: IGNITE-3564 URL: https://issues.apache.org/jira/browse/IGNITE-3564 Project: Ignite Issue Type: Task

Re: Distributed joins for JDBC

Our JDBC drivers already have connection properties that correspond to SqlFieldsQuery properties. So we can just add support of this parameter to connection string parser. Corresponding ticket created IGNITE-3563 ( https://issues.apache.org/jira/browse/IGNITE-3563 ). On Mon, Jul 25, 2016 at

[jira] [Created] (IGNITE-3563) JDBC drivers should support distributed joins flag

Andrey Gura created IGNITE-3563: --- Summary: JDBC drivers should support distributed joins flag Key: IGNITE-3563 URL: https://issues.apache.org/jira/browse/IGNITE-3563 Project: Ignite Issue

[jira] [Created] (IGNITE-3562) Dependency to outdate Lucene 3.5.0

Alexander Veit created IGNITE-3562: -- Summary: Dependency to outdate Lucene 3.5.0 Key: IGNITE-3562 URL: https://issues.apache.org/jira/browse/IGNITE-3562 Project: Ignite Issue Type: Bug

Re: Distributed joins for JDBC

Hi, I've added IGNITE-3561 for .NET. However, there is not enough documentation for the new property: * What are the implications of enabling distributed joins? * Does it affect performance of non-join queries? * Does it affect performance of colocated joins? * Why is it disabled by default?

[jira] [Created] (IGNITE-3561) .NET: DistributedJoins property in SqlQuery & SqlFieldsQuery

Pavel Tupitsyn created IGNITE-3561: -- Summary: .NET: DistributedJoins property in SqlQuery & SqlFieldsQuery Key: IGNITE-3561 URL: https://issues.apache.org/jira/browse/IGNITE-3561 Project: Ignite

Re: Data compression in Ignite 2.0

This will make sense only for rare cases when you have very large objects stored, which can be effectively compressed. And even then it will introduce slowdown on all the operations, which often will not be acceptable. I guess only few users will find this feature useful, thus I think it does not

Re: Distributed joins for JDBC

BTW this approach will be applicable to ODBC as well as far as I understand, so it will be consistent. Sergi 2016-07-25 10:04 GMT+03:00 Sergi Vladykin : > I don't think it makes sense to extend JDBC this way because usually if > one have access to Java API he most

Re: Distributed joins for JDBC

I don't think it makes sense to extend JDBC this way because usually if one have access to Java API he most probably will use Ignite API. If for some reason they use JDBC it means that it is an application which was aimed to work with any RDBMS and should not know about quirks of some particular

Data compression in Ignite 2.0

Hi, All! I would like to propose one more feature for Ignite 2.0. Data compression for data in binary format. Binary format is stored as field name + field data. So we have a description. How about to add one more byte to binary data descriptor: *Compressed*: 0 - Data stored as is (no

Distributed joins for JDBC

Hi, Last week distributed joins functionality was merged, but one thing was overlooked. Distributed joins should be explicitly enabled using using method 'setDistributedJoins' available in java API (SqlQuery/SqlFieldsQuery). First, this parameter should be also added in .Net/C++/REST API, this is

[GitHub] ignite pull request #878: IGNITE-3399 Add support for primitive type names i...

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