GitHub user alamar opened a pull request:
https://github.com/apache/ignite/pull/2816
IGNITE-2766 Essais: Opportunistic reopen cache.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-2766
Vladimir Ozerov created IGNITE-6573:
---
Summary: SQL: Document WRAP_KEY and WRAP_VALUE commands
Key: IGNITE-6573
URL: https://issues.apache.org/jira/browse/IGNITE-6573
Project: Ignite
Issue
Denis Mekhanikov created IGNITE-6571:
Summary: Service not found exception when calling service method
before initialization finished
Key: IGNITE-6571
URL: https://issues.apache.org/jira/browse/IGNITE-6571
I like ignitesql.
D.
On Oct 6, 2017, 4:49 PM, at 4:49 PM, Vladimir Ozerov
wrote:
>Denis,
>
>Setting default host to 127.0.0.1 is bad idea, because it mean that in
>practice users would have to change the script always. Instead, we
>should
>accept host name as argument.
How about sqlconsole.sh or sqlcmd.sh ?
On Fri, Oct 6, 2017 at 6:04 PM, wrote:
> I like ignitesql.
>
> D.
>
> On Oct 6, 2017, 4:49 PM, at 4:49 PM, Vladimir Ozerov
> wrote:
> >Denis,
> >
> >Setting default host to 127.0.0.1 is bad idea, because it
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/2784
---
Denis,
Setting default host to 127.0.0.1 is bad idea, because it mean that in
practice users would have to change the script always. Instead, we should
accept host name as argument. This is perfectly fine from usability
perspective, most tools work this way (i.e. throw error when started
without
Denis
The link below has included sqlline. Please take a look:
https://ci.ignite.apache.org/viewLog.html?buildId=875441=IgniteRelease_XxxFromMirrorIgniteRelease3PrepareVote=artifacts#!1rrb2,-wpvx2aopzexz
On Thu, Oct 5, 2017 at 7:48 PM, Denis Magda wrote:
> Here is the
Yakov,
Ideally - all of them :) Or at least those APIs that execute remote
operations (all cache operations, compute, service proxy invocations, ...).
Having an ability to add custom metadata to this kind of operations can be
very valuable for auditing purposes.
-Val
On Thu, Oct 5, 2017 at 8:38
> But, we need to support “help” (-h, -help) argument listing all the
> parameters accepted by the tools.
Meant accepted by the ignitesql script only such as host name.
—
Denis
> On Oct 6, 2017, at 12:20 PM, Denis Magda wrote:
>
> Really nice, could click through the
Created a ticket: https://issues.apache.org/jira/browse/IGNITE-6575
-Val
On Thu, Oct 5, 2017 at 8:55 AM, Yakov Zhdanov wrote:
> >>Second of all, it seems that we send a network message from primary node
> to
> local backup, which doesn't make much sense to me and looks
Valentin Kulichenko created IGNITE-6575:
---
Summary: IgniteCache#get can return stale value when executed on
backup
Key: IGNITE-6575
URL: https://issues.apache.org/jira/browse/IGNITE-6575
Really nice, could click through the getting started [1] in a minute!
+1 to rename the script to “ignitesql”. Vladimir’s point makes total sense.
However, tend to disagree that the host has to be requested all the times. We
never request a configuration or host name for ignite.sh, visor or web
On Fri, Oct 6, 2017 at 9:04 AM, Anton Vinogradov
wrote:
> How about sqlconsole.sh or sqlcmd.sh ?
>
Shouldn't we have "ignite" in the name?
How does the binding happen? Can we bind to everything, like we do in
Ignite?
On Fri, Oct 6, 2017 at 2:51 PM, Denis Magda wrote:
> Thought over 127.0.0.1 as a default host once again. The bad thing about
> it is that the user gets a lengthy exception stack trace if Ignite is
Vasiliy Sisko created IGNITE-6568:
-
Summary: Failed to DROP table created by DDL query after restart
Key: IGNITE-6568
URL: https://issues.apache.org/jira/browse/IGNITE-6568
Project: Ignite
Github user voipp closed the pull request at:
https://github.com/apache/ignite/pull/2751
---
Thanks, Alexey.
I doubt anyone in the community will be able to answer your question here.
I am assuming that thread ID is not going to be enough to identify a
transaction, given that suspend happens in one thread, and resume in
another. However, to tell for sure would require a better
GitHub user voipp reopened a pull request:
https://github.com/apache/ignite/pull/2751
ignite-5714-8
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/voipp/ignite
ignite-5714-local-lock-not-covered
Alternatively you can review
Vasiliy Sisko created IGNITE-6569:
-
Summary: DROP table is frozen in special case
Key: IGNITE-6569
URL: https://issues.apache.org/jira/browse/IGNITE-6569
Project: Ignite
Issue Type: Bug
GitHub user apopovgg opened a pull request:
https://github.com/apache/ignite/pull/2813
IGNITE-6272: .NET: Propagate multiple services deployment
The following changes were made:
1. Java code:
added new JNI methods wrappers to Java: package
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/2808
---
GitHub user alexpaschenko opened a pull request:
https://github.com/apache/ignite/pull/2815
IGNITE-6568 cache descriptor SQL attribute store/restore fix
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite
On Thu, Oct 5, 2017 at 1:24 PM, Alexey Goncharuk wrote:
> Guys,
>
> I think we should not limit this functionality to http-rest only. We
should
> add this information to one of the MBeans as the primary information
> source. Then this should be added as a client
GitHub user sergey-chugunov-1985 opened a pull request:
https://github.com/apache/ignite/pull/2814
Ignite 2.1.6
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-2.1.6
Alternatively you can review
25 matches
Mail list logo