Re: Add new event in putblic API

Just my opinion about UnhandledExceptionEvent 1) All events are disabled by default. So user will need to configure. 2) Events buffer is 10_000 by default and UnhandledExceptionEvent could be evicted from buffer by other frequent events. 3) User should collect events periodically. So from my

Re: Add new event in putblic API

We can add separate callback as CQ setter. Exception event doesn't look very useful for user to me. 08 нояб. 2016 г. 10:39 пользователь "Anton Vinogradov" < avinogra...@gridgain.com> написал: > This will break compatibility with user code in case this method will not > be optional. > > On Tue,

Re: Add new event in putblic API

This will break compatibility with user code in case this method will not be optional. On Tue, Nov 8, 2016 at 10:32 AM, Yakov Zhdanov wrote: > I would better add onError() to CQ local listener. > > --Yakov > > 2016-11-08 10:29 GMT+03:00 Anton Vinogradov

Re: Add new event in putblic API

I would better add onError() to CQ local listener. --Yakov 2016-11-08 10:29 GMT+03:00 Anton Vinogradov : > Vova, > > We just give user 2 additional tips. > We write exception to ExceptionRegistry and send event. > In case user will use some management console he will

Re: Add new event in putblic API

Vova, We just give user 2 additional tips. We write exception to ExceptionRegistry and send event. In case user will use some management console he will see big red warning window. On Tue, Nov 8, 2016 at 10:22 AM, Vladimir Ozerov wrote: > I am not quite sure how user is

Re: Add new event in putblic API

I am not quite sure how user is going to use it. Could you please provide pseudocode for that? In particular, I do not understand how user will understand the source of this exception, and how will he match exception event with particular CQ listener. On Tue, Nov 8, 2016 at 10:18 AM, Anton

Re: Add new event in putblic API

UnhandledExceptionEvent will be used for notification. Current code will just write error to log, new code will write error to log, write it to the ExceptionRegistry and inform user using UnhandledExceptionEvent On Tue, Nov 8, 2016 at 1:41 AM, Dmitriy Setrakyan wrote: >

Re: Connecting to Ignite from Tableau

Denis, I am not sure it requires specific documentation. Tableau is just one of many applications which use ODBC to connect to some data source. On Tue, Nov 8, 2016 at 1:50 AM, Denis Magda wrote: > Guys, > > As far as I aware with the help of Ignite ODBC driver it’s

[GitHub] ignite pull request #1214: rest_support_keyForAnyObject

GitHub user fs7744 opened a pull request: https://github.com/apache/ignite/pull/1214 rest_support_keyForAnyObject add support key for any object in rest You can merge this pull request into a Git repository by running: $ git pull https://github.com/fs7744/ignite

Contribution: Integration with Striim

Igniters, Recently I’ve came across the following article [1] that explains how the integration with Striim helps Hazelcast users to propagate updates happened on a database side to the cluster. The integration is useful for scenarios when the database is updated from several sources and the

Connecting to Ignite from Tableau

Guys, As far as I aware with the help of Ignite ODBC driver it’s feasible to connect to Ignite cluster from Tableau [1]. However I didn’t find any documentation related to this support. Igor, are there any specific steps and hints I should follow if I want to connect to Ignite from above

Re: ODBC processor default behaviour

Thanks to this old discussion I was finally able to form an understanding on how Ignite ODBC driver connects to the cluster and executes SQL queries over it. Igor, by some reason we didn’t add any information around ODBC processor and configuration to our documentation page. Let’s fill this

Re: Add new event in putblic API

I think I am missing something. If you are saying that we have no way to notify CQ listeners if the notification message failed, how do you plan to notify them about the failure? What if the failure message also fails? On Sun, Nov 6, 2016 at 11:45 PM, Anton Vinogradov wrote: >

[jira] [Created] (IGNITE-4184) Document how ODBC drivers works with the cluster

Denis Magda created IGNITE-4184: --- Summary: Document how ODBC drivers works with the cluster Key: IGNITE-4184 URL: https://issues.apache.org/jira/browse/IGNITE-4184 Project: Ignite Issue Type:

Re: TX savepoints

Couldn't agree more about ODBC and JDBC. We must support savepoints from SLQ, given the DML functionality being planned for 1.8 release. On Mon, Nov 7, 2016 at 11:23 AM, Denis Magda wrote: > This is how how the savepoints are supported by PostgreSQL [1], Oracle [2] > and

Re: TX savepoints

This is how how the savepoints are supported by PostgreSQL [1], Oracle [2] and MySQL [3]. The implementation details and behavior are pretty the same and similar to the Yakov’s proposal. It worth to note that all the engines support multiple savepoints per transaction named uniquely and the

Re: IGNITE-3999: Design discussion

I do support Sergi’s proposal. We already set aliases (setAliases(…)) and indexes (setIndexes(…)) in a similar way. — Denis > On Nov 7, 2016, at 12:33 AM, Sergi Vladykin wrote: > > I don't think per field configuration makes a big sense. I would just add > another

[GitHub] ignite pull request #1213: IGNITE-4183: Returning size of the fixed-sized co...

GitHub user isapego opened a pull request: https://github.com/apache/ignite/pull/1213 IGNITE-4183: Returning size of the fixed-sized columns on fetch. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite

Re: Off-Heap SQL Indexes

Sergi, > May be you use > some weird email client which renders >> signs wrong? Right, my Apple’s Mail agent omitted ‘>’ character from your original statement applying some HTML formatting. Prachi, please update all the docs keeping in my that this sentence is technically correct >> SQL

Re: Apache Ignite 1.8 Release

Igniter, I constantly see a lot of complains around the situation that Ignite still uses an old Spark version for its Spark module. This definitely prevents from using Ignite inside of Spark community. Here you can see the latest concerns and complains raised in our chat

Re: TX savepoints

Does anyone know how MySQL or PostgreSQL work with checkpoints? Do they support it in a similar way? On Mon, Nov 7, 2016 at 5:58 AM, Yakov Zhdanov wrote: > Alex, I think we should put consecutive checkpoints to stack thus your > example should be illegal and should result

[jira] [Created] (IGNITE-4183) ODBC: empty value in a particular row breaks reading other rows in the column

Igor Sapego created IGNITE-4183: --- Summary: ODBC: empty value in a particular row breaks reading other rows in the column Key: IGNITE-4183 URL: https://issues.apache.org/jira/browse/IGNITE-4183 Project:

Re: TX savepoints

Alex, I think we should put consecutive checkpoints to stack thus your example should be illegal and should result to exception. And we will throw exception on rollback to CP if CP is not defined. --Yakov 2016-11-07 14:23 GMT+03:00 Alexey Goncharuk : > We also should

[jira] [Created] (IGNITE-4182) Improve error output when query parsing failed.

Igor Sapego created IGNITE-4182: --- Summary: Improve error output when query parsing failed. Key: IGNITE-4182 URL: https://issues.apache.org/jira/browse/IGNITE-4182 Project: Ignite Issue Type:

[jira] [Created] (IGNITE-4181) The several runs of ServiceExample may cause NPE

, 172.25.4.107, 2001:0:9d38:6ab8:34b2:9f3e:3c6f:269], sockAddrs=[/2001:0:9d38:6ab8:34b2:9f3e:3c6f:269:0, /127.0.0.1:0, /0:0:0:0:0:0:0:1:0, work-pc/172.25.4.107:0], discPort=0, order=10, intOrder=7, lastExchangeTime=1478522239236, loc=false, ver=1.7.3#20161107-sha1:5132ac87, isClient=true] [15:37:20,063

Re: TX savepoints

We also should define savepoint behavior and API rules for each of the transaction concurrency and isolation types. * Should rollbackToSavepoint() always release locks or clear saved optimistic versions? * Are forward-rollbacks allowed, e.g. try (Transaction tx =

[jira] [Created] (IGNITE-4180) Web console: Query paragraph is not extended from collapsed state on move by "Scroll to query" link

Vasiliy Sisko created IGNITE-4180: - Summary: Web console: Query paragraph is not extended from collapsed state on move by "Scroll to query" link Key: IGNITE-4180 URL:

Re: TX savepoints

Hi, Yakov I suppose it's very very handy feature. My two cents are following: - number of savepoints may be more than one per transaction - what's about RELEASE SAVEPOINT statement? On Mon, Nov 7, 2016 at 11:24 AM, Yakov Zhdanov wrote: > Guys, > > Let's think of

[jira] [Created] (IGNITE-4179) ExampleNodeStartup fails with IllegalStateException: Cache stopped: CacheQueryExamplePersons for CacheQueryExample

Sergey Kozlov created IGNITE-4179: - Summary: ExampleNodeStartup fails with IllegalStateException: Cache stopped: CacheQueryExamplePersons for CacheQueryExample Key: IGNITE-4179 URL:

[GitHub] ignite pull request #1202: IGNITE-4119 .NET: Add TransactionDeadlockExceptio...

Github user ptupitsyn closed the pull request at: https://github.com/apache/ignite/pull/1202 --- 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 #1192: IGNITE-4028 Get rid of OP_META in PlatformAbstrac...

Github user ptupitsyn closed the pull request at: https://github.com/apache/ignite/pull/1192 --- 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-4178) Support permission builder

Dmitriy Govorukhin created IGNITE-4178: -- Summary: Support permission builder Key: IGNITE-4178 URL: https://issues.apache.org/jira/browse/IGNITE-4178 Project: Ignite Issue Type:

Re: IGNITE-3999: Design discussion

I don't think per field configuration makes a big sense. I would just add another property to QueryEntity like setCaseInsensitiveFields(Set fields). Sergi 2016-11-07 9:09 GMT+03:00 Vladimir Ozerov : > Hi Amir, > > Having POJO class QueryField looks like a good idea to

TX savepoints

Guys, Let's think of implementing savepoints for Ignite transactions. For me, this is not too hard to do. Having "savepoints" seems to be pretty handy. Please consider the following snippet. ignite.transactions.; INSERT INTO table1 VALUES (1); SAVEPOINT my_savepoint; INSERT INTO table1 VALUES