Valentin Kulichenko created IGNITE-6219:
---
Summary: IgniteCache#loadCache executes local load in caller thread
Key: IGNITE-6219
URL: https://issues.apache.org/jira/browse/IGNITE-6219
Project:
Igniters,
Let me introduce Julian Hyde [1], creator of SQLLine tool and our Apache mate,
Julian,
Please grant that Apache Ignite community a permission to include SQLLine [2]
it in every Ignite deliverable (source, binary). It’s planned to suggest the
tool as a default command line SQL
Ideally, SQL API has to be completely decoupled from cache API. Otherwise
we will keep getting issues like this.
let's introduce top level API (IgniteSql?) and add everything there.
-Val
On Tue, Aug 29, 2017 at 7:47 PM Denis Magda wrote:
> Igniters,
>
> Not sure we
Igniters,
That’s one more feedback about CREATE TABLE usage in practice.
The command automatically creates an IgniteCache naming it SQL_PUBLIC_{TABLE}.
So, if a Person table is created you’ll have SQL_PUBLIC_PERSON cache in the
cluster.
Honestly, if you keep to SQL APIs the cache name won’t
Igniters,
Not sure we discussed this before, so let me start a new thread.
It’s claimed the command is supported from native Java, .NET, C++ APIs but I
had hard time trying to use it from there. Imagine this simple statement to be
called from Java source code:
SqlFieldsQuery query = new
The Project Management Committee (PMC) for Apache Ignite has invited Pavel
Tupitsyn to become a PMC member and we are pleased to announce that he has
accepted the role.
Being a PMC member enables assistance with the management and to guide the
direction of the project.
Pavel, is a veteran of
GitHub user ilantukh opened a pull request:
https://github.com/apache/ignite/pull/2545
For testing
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-2.1.4-6212
Alternatively you can review and apply
Denis Magda created IGNITE-6218:
---
Summary: Document logging capabilities of Ignite
Key: IGNITE-6218
URL: https://issues.apache.org/jira/browse/IGNITE-6218
Project: Ignite
Issue Type: Task
GitHub user agura opened a pull request:
https://github.com/apache/ignite/pull/2544
Tx recovery fix
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/agura/incubator-ignite tx-recovery-fix
Alternatively you can review and apply
GitHub user isapego opened a pull request:
https://github.com/apache/ignite/pull/2543
IGNITE-6119: Added 'lazy' flag to ODBC
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-6119
Alternatively you
Github user isapego closed the pull request at:
https://github.com/apache/ignite/pull/2533
---
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
Hello Andrey.
I'm not sure that BigDecimal makes for a passable SQL DECIMAL. Somebody
have to look at the standard sooner or later.
BigDecimal works as values as well, and BigInteger don't work, too.
I've created this remedy pull request and now am waiting for tests:
Serge,
The attachment is missing. Try to share it via google drive or other storage.
—
Denis
> On Aug 29, 2017, at 2:38 AM, Serge Puchnin wrote:
>
> Hi !
>
> As I can see, there is some room for documentation improvement.
> As a sample of documentation, I've
Igor,
Could you share a test to reproduce the issue?
—
Denis
> On Aug 29, 2017, at 3:59 AM, igor.tanackovic
> wrote:
>
> Upgraded Ignite from 2.0.0 to 2.1.0 and ran into a thread deadlock on Ignite
> startup. I noticed the deadlock once I added CacheStore into a
GitHub user ptupitsyn opened a pull request:
https://github.com/apache/ignite/pull/2542
IGNITE-5905 .NET: Thin client: cache.Get for primitives
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-5905
Taras Ledkov created IGNITE-6217:
Summary: Add benchmark to compare JDBC drivers and native SQL
execution
Key: IGNITE-6217
URL: https://issues.apache.org/jira/browse/IGNITE-6217
Project: Ignite
Ilya,
Ignite doesn't support scale\precision constrains for Decimal type,
so H2 treat them as Decimals with highest precision.
It is different issue as BigDecimal keys works, but with limitation.
However, BigInteger keys looks like doesn't work at all.
Disable having BigDecimal & BigInteger
GitHub user alexpaschenko opened a pull request:
https://github.com/apache/ignite/pull/2541
IGNITE-5620
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-5620
Alternatively you can review and apply
Hello fellow Igniters,
We have troubles with BigDecimal and BigInteger types used as cache keys
and then referenced in SQL.
As far as I see, our implementation of SQL considers BigDecimal to be SQL's
DECIMAL type.
But semantics of BigDecimal are different. BigDecimal("4.2") not equals to
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/2511
---
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
Ivan Rakov created IGNITE-6216:
--
Summary: Add CheckpointWriteOrder enum in .NET persistent store
configuration
Key: IGNITE-6216
URL: https://issues.apache.org/jira/browse/IGNITE-6216
Project: Ignite
GitHub user ntikhonov opened a pull request:
https://github.com/apache/ignite/pull/2540
Ignite 2.1.3.b5
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-2.1.3.b5
Alternatively you can review and
GitHub user oleg-ostanin opened a pull request:
https://github.com/apache/ignite/pull/2539
Ignite 5817 x
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-5817-x
Alternatively you can review and
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/2446
---
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
Igniters,
Does anyone else see potential issues on user side with current approach?
Sam, is this JCache requirement?
--Yakov
2017-08-29 15:16 GMT+03:00 Nikolay Izhikov :
> Yakov.
>
> I think exception equals `true` is intended behavior.
>
> Filter evaluation
GitHub user ilantukh opened a pull request:
https://github.com/apache/ignite/pull/2538
IGNITE-6212 : Fixed assertion error for invalid node2part.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-6212
Denis Mekhanikov created IGNITE-6214:
Summary: Client hangs when executing SQL updates
Key: IGNITE-6214
URL: https://issues.apache.org/jira/browse/IGNITE-6214
Project: Ignite
Issue Type:
Vladislav Pyatkov created IGNITE-6213:
-
Summary: Unexpected setting local deployment owner anyone node
Key: IGNITE-6213
URL: https://issues.apache.org/jira/browse/IGNITE-6213
Project: Ignite
Ilya Lantukh created IGNITE-6212:
Summary: Assertion error: Invalid node2part
Key: IGNITE-6212
URL: https://issues.apache.org/jira/browse/IGNITE-6212
Project: Ignite
Issue Type: Bug
Dear Igniters,
I would like to know if guard() and checkClusterState() methods are always
called consistently in IgniteKernal.
Let's look at the list:
Out of cluster(), localNode(), compute(), message(), events(),
executorService(), services() only the last one is guarded by
checkClusterState()
Yakov.
I think exception equals `true` is intended behavior.
Filter evaluation implementation from master - [1]
Test from master to check filter exception(without explicit asserts
checking listeners call) - [2]
Here is my quick test with asserts on listener call after filter exception:
```
I've replied in JIRA. Yakov, please have a look as well.
On Wed, Aug 23, 2017 at 6:44 PM, Vyacheslav Daradur
wrote:
> Hi,
>
> >> ticket filed: https://issues.apache.org/jira/browse/IGNITE-5879
> I've done it, could someone review it?
>
> 2017-07-31 11:13 GMT+03:00 Pavel
GitHub user oignatenko opened a pull request:
https://github.com/apache/ignite/pull/2537
IGNITE-6193 ML profile is missing in 2.1 binary release
- verified with diffs overview and trial local build
You can merge this pull request into a Git repository by running:
$ git pull
> If filter throws exception entry would be passed to listener.
this is strange. Imagine a filter that very rarely throws some runtime
exception due to external or environmental reasons, but in case of normal
execution filter evaluates to false. In case of error entry is passed to a
local
Hi, Yakov.
If filter throws exception entry would be passed to listener.
> Nikolay, I would also suggest you extract some super class for continuous
> query. It will help to avoid code duplicates.
Yes, I will do this after reaching consensus on API changes.
29.08.2017 14:04, Yakov Zhdanov
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/2448
---
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
I don't like the idea of having separate class, but it seems to be the only
way as there are too many API and generics differences.
Nikolay, I would also suggest you extract some super class for continuous
query. It will help to avoid code duplicates.
As far as remote transformer failure - we
Nikolay,
> 2. What behavior is expected if transformer throws exception for some
event? I see following options:
Client should be notified, I vote for
> Introduce special callback. onTransformError?
On Tue, Aug 29, 2017 at 1:36 PM, Nikolay Izhikov
wrote:
> Hello,
GitHub user DmitriyGovorukhin opened a pull request:
https://github.com/apache/ignite/pull/2536
IGNITE-6210 Size of the checkpoint buffer is limited
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite
Hello, Igniters.
I'm working on IGNITE-425 [1] issue.
Text of issue:
===
Currently if updated entry passes the filter, it is sent to node
initiated the query entirely. It would be good to provide user with the
ability to transform entry and, for example, select only fields that are
Igor Sapego created IGNITE-6211:
---
Summary: ODBC: SQLBindParameter should not unbind parameter if the
ParameterValuePtr is NULL
Key: IGNITE-6211
URL: https://issues.apache.org/jira/browse/IGNITE-6211
Dmitriy Govorukhin created IGNITE-6210:
--
Summary: inefficient memory consumption for checkpoint buffer
Key: IGNITE-6210
URL: https://issues.apache.org/jira/browse/IGNITE-6210
Project: Ignite
GitHub user gvvinblade opened a pull request:
https://github.com/apache/ignite/pull/2535
IGNITE-6182
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-6182
Alternatively you can review and apply
Oleg Ostanin created IGNITE-6209:
Summary: Build Ignite.NET NuGet packages for Apache-Ignite release
on CI
Key: IGNITE-6209
URL: https://issues.apache.org/jira/browse/IGNITE-6209
Project: Ignite
Hi !
As I can see, there is some room for documentation improvement.
As a sample of documentation, I've prepared a description of "CREATE INDEX"
statement.
What’s your opinion?
What can be improved?
What should be added?
Thanks a lot!
---
Serge
Vladimir Ozerov created IGNITE-6208:
---
Summary: SQL: Add documentation for lazy query execution
Key: IGNITE-6208
URL: https://issues.apache.org/jira/browse/IGNITE-6208
Project: Ignite
Issue
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/2491
---
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
47 matches
Mail list logo