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 poin
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, No
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 :
>
> > Vova,
> >
> > We just give user 2
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 see big red warning
> window
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 going to use it. Could
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 Vinogra
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:
> I think I am missing som
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 feasible to
> connect to Ign
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 rest_support_k
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 cl
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 mentio
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 ga
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:
> Dmitriy,
>
> In ca
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: T
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 MySQL [3]. The implement
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 REL
Crossposting to dev list.
-- Forwarded message --
From: Andrey Mashenkov
Date: Thu, Nov 3, 2016 at 10:04 PM
Subject: Re: Null column values - bug
To: u...@ignite.apache.org
Yes, you are right. This is a bug.
It seems there should be smth like this:
wasNull == curr.get(colIdx -
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 property to QueryEntity like
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 ignite-
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 eng
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
https://gitter.im/apach
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 to exception. And we wi
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:
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 define savepoint behavior an
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: Ta
, 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
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 = ignite.transactions().txStart()
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: https://issues.apache.org/jira/browse/IGNITE-4
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 implementing savepoints for I
Sergey Kozlov created IGNITE-4179:
-
Summary: ExampleNodeStartup fails with IllegalStateException:
Cache stopped: CacheQueryExamplePersons for CacheQueryExample
Key: IGNITE-4179
URL: https://issues.apache.org/jira
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 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
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: Improveme
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 me. Because we will
> be
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 (2
35 matches
Mail list logo