On Wed, Jul 27, 2016 at 2:29 AM, Semyon Boikov wrote:
> Sure Dmitry, we will run tests with large data set.
>
> Regarding 1.7. release: If there are no objections I'm going to cut off 1.7
> branch and start prepare it for release.
>
In my opinion this is a great addition to Ignite and is definit
Alexey Kuznetsov created IGNITE-3589:
Summary: Add support for distributed joins to SQL screen on Web
Console
Key: IGNITE-3589
URL: https://issues.apache.org/jira/browse/IGNITE-3589
Project: Ignit
Sure Dmitry, we will run tests with large data set.
Regarding 1.7. release: If there are no objections I'm going to cut off 1.7
branch and start prepare it for release.
On Wed, Jul 27, 2016 at 9:15 AM, Dmitriy Setrakyan
wrote:
> On Wed, Jul 27, 2016 at 2:09 AM, Semyon Boikov
> wrote:
>
> > R
Nikita,
That was my intention: "we may need to provide a better facility to inject
user's logic here..."
Andrey,
About compression, once again - DB2 is a row-based DB and they can compress
:)
On Wed, Jul 27, 2016 at 12:56 PM, Nikita Ivanov wrote:
> Very good points indeed. I get the compressio
Hm... I would prefer to find a way to handle Enums automatically.
In case if user expects a String, can we catch an exception and do
automatic conversion at that time? In this case, we could catch the
exception once and remember the decision. Will something like this work?
D.
On Tue, Jul 26, 201
What is the ticket number for this. Is the new API documented there?
On Tue, Jul 26, 2016 at 11:36 AM, Sergi Vladykin
wrote:
> I don't see anything ugly in empty iterator, sorry if I insulted your taste
> of beauty.
>
> If you will take a look at Jdbc, you will see that Statement.executeUpdate
>
On Wed, Jul 27, 2016 at 2:09 AM, Semyon Boikov wrote:
> Regarding distributed join testsing: we added tests verifying correct join
> behavior and correct execution plan generation for various SQL queries,
> tests for joins for various cache types (different number of backups,
> partitioned/replic
Regarding distributed join testsing: we added tests verifying correct join
behavior and correct execution plan generation for various SQL queries,
tests for joins for various cache types (different number of backups,
partitioned/replicated), there are tests verifying correct distributed
joins resul
I am very confused still. Ilya, can you please explain what happens in
Cassandra if user calls IgniteCache.putAll(...) method?
In Ignite, if putAll(...) is called, Ignite will make the best effort to
execute the update as a batch, in which case the performance is better.
What is the analogy in Cas
Very good points indeed. I get the compression in Ignite question quite
often and Hana reference is a typical lead in.
My personal opinion is still that in Ignite *specifically* the compression
is best left to the end-user. But we may need to provide a better facility
to inject user's logic here..
Yes, I'm working on it, updated ticket.
On Tue, Jul 26, 2016 at 5:06 PM, Dmitriy Setrakyan
wrote:
> On Tue, Jul 26, 2016 at 1:43 AM, Semyon Boikov
> wrote:
>
> > We already have similar issue reproduced in our benchmarks -
> > https://issues.apache.org/jira/browse/IGNITE-3300. I think this is
>
Dictionary compression requires some knowledge about data being compressed. For
example, for numeric types a range of values must be known so that the
dictionary can be generated. For strings, the number of unique values of the
column is the key piece of input into the dictionary generation.
SAP
Dmitriy,
There is absolutely same approach for all async read/write/delete
operations - Cassandra session just provides executeAsync(statement) function
for all type of operations.
To be more detailed about Cassandra batches, there are actually two types
of batches:
1) *Logged batch* (aka atomic
On Tue, Jul 26, 2016 at 5:53 PM, Igor Rudyak wrote:
> Hi Valentin,
>
> For writeAll/readAll Cassandra cache store implementation uses async
> operations (http://www.datastax.com/dev/blog/java-driver-async-queries)
> and
> futures, which has the best characteristics in terms of performance.
>
>
Th
Hi Valentin,
For writeAll/readAll Cassandra cache store implementation uses async
operations (http://www.datastax.com/dev/blog/java-driver-async-queries) and
futures, which has the best characteristics in terms of performance.
Cassandra BATCH statement is actually quite often anti-pattern for tho
Hi Igor,
I noticed that current Cassandra store implementation doesn't support
batching for writeAll and deleteAll methods, it simply executes all updates
one by one (asynchronously in parallel).
I think it can be useful to provide such support and created a ticket [1].
Can you please give your i
Valentin Kulichenko created IGNITE-3588:
---
Summary: Cassandra store should use batching in writeAll and
deleteAll methods
Key: IGNITE-3588
URL: https://issues.apache.org/jira/browse/IGNITE-3588
P
Hi Anton, devs,
it seems that a commit was missed in the merge for
https://issues.apache.org/jira/browse/IGNITE-3323
The current state of master might not be good. Please see my comments
on the ticket.
Thanks
Jens
On Tue, Jul 26, 2016 at 9:59 AM, NoTrueScotsman
wrote:
> Ready for review:
> h
GitHub user iveselovskiy opened a pull request:
https://github.com/apache/ignite/pull/899
Ignite 1.6.3 1637
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-1.6.3-1637
Alternatively you can review an
Igor Sapego created IGNITE-3587:
---
Summary: ODBC: Add Distributed Joins support to ODBC.
Key: IGNITE-3587
URL: https://issues.apache.org/jira/browse/IGNITE-3587
Project: Ignite
Issue Type: Task
Igor Sapego created IGNITE-3586:
---
Summary: CPP: Make QueryArgument and QueryArgumentBase classes
non-public.
Key: IGNITE-3586
URL: https://issues.apache.org/jira/browse/IGNITE-3586
Project: Ignite
Igor Sapego created IGNITE-3585:
---
Summary: CPP: Rework methods that accept containers so any
container could be used with them.
Key: IGNITE-3585
URL: https://issues.apache.org/jira/browse/IGNITE-3585
Pr
I don't see anything ugly in empty iterator, sorry if I insulted your taste
of beauty.
If you will take a look at Jdbc, you will see that Statement.executeUpdate
method returns number of updated rows, I'd prefer to return the same
information, so it will not be empty (beauty is restored!).
Sergi
Igor Sapego created IGNITE-3584:
---
Summary: CPP: Refactor BinaryType class template.
Key: IGNITE-3584
URL: https://issues.apache.org/jira/browse/IGNITE-3584
Project: Ignite
Issue Type: Task
I see your point. But what about my concerns from initial post?
Particularly about signatures of existing methods? I personally don't
like an option of query() method always returning an empty iterator
for any non-select query, it seems ugly design wise.
- Alex
2016-07-26 18:15 GMT+03:00 Sergi Vl
BTW, the simplest way to solve this issue is to allow running SQL commands
inside of SqlFieldsQuery.
We may add some additional convenience API for updates if we want, but JDBC
client will always call it like this:
cache.query(new SqlFieldsQuery("INSERT INTO MY_TABLE
VALUES(?,?)").setArgs(1,2));
Igor Sapego created IGNITE-3583:
---
Summary: CPP: Replace passing by value with passing by reference
where it is possible.
Key: IGNITE-3583
URL: https://issues.apache.org/jira/browse/IGNITE-3583
Project:
Igor Sapego created IGNITE-3582:
---
Summary: CPP: Replace pointers with references in function
signatures where it's possible.
Key: IGNITE-3582
URL: https://issues.apache.org/jira/browse/IGNITE-3582
Proje
Igor Sapego created IGNITE-3581:
---
Summary: CPP: Place different enums and constants in separate
namespaces or structs.
Key: IGNITE-3581
URL: https://issues.apache.org/jira/browse/IGNITE-3581
Project: Ig
I don't like any pre-parsing, especially with some libraries other than H2.
H2 itself has enough quirks to multiply it on quirks of another library.
This is exactly what I was talking about - we need some single entry point
on API for all the SQL commands and queries. Thats why I suggested
SqlUpda
GitHub user isapego opened a pull request:
https://github.com/apache/ignite/pull/898
IGNITE-3577: Added "Address" connection string argument
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/isapego/ignite ignite-3577
Alternativel
On Tue, Jul 26, 2016 at 1:43 AM, Semyon Boikov wrote:
> 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
GitHub user ptupitsyn opened a pull request:
https://github.com/apache/ignite/pull/897
IGNITE-3427 .NET: Move examples from Spring XML to app.config
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ptupitsyn/ignite ignite-3427
Al
Sergey Kozlov wrote:
>> For approach 1: Put a large object into a partition cache will
force to update
the dictionary placed on replication cache. It may be time-expense
operation.
The dictionary will be built only once. And we could control what should be
put into dictionary, for example, we coul
Vladimir Ozerov created IGNITE-3580:
---
Summary: IGFS: Allow IGFS tasks execution on machines where IGFS
is not configured.
Key: IGNITE-3580
URL: https://issues.apache.org/jira/browse/IGNITE-3580
Proj
Guys,
I would like to advance the discussion further. There's one quite
important question that arose based on current state of work on this
issue. If we use some kind of interactive console, like Visor, then
how should it know whether SQL query it is requested to execute
returns a result set or n
GitHub user iveselovskiy opened a pull request:
https://github.com/apache/ignite/pull/896
Ignite 1.6.3 3343
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-1.6.3-3343
Alternatively you can review an
Github user EdShangGG closed the pull request at:
https://github.com/apache/ignite/pull/885
---
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 e
Looks like the same issue as reported by Agneeswaran:
http://apache-ignite-users.70518.x6.nabble.com/Issue-with-concurrent-users-on-Ignite-1-6-0-ODBC-td6217.html#a6385
Best Regards,
Igor
On Tue, Jul 26, 2016 at 8:43 AM, Semyon Boikov wrote:
> We already have similar issue reproduced in our benc
Pavel,
In Web Console [1] we have generation of Spring XML and appropriate Java
code generation.
And from my experience it is not trivial thing to generate Spring XML in
some cases (if we will write code by ourselves).
If we will use Spring marshaling - that will bring a dependency from Spring
t
Ready for review:
https://issues.apache.org/jira/browse/IGNITE-3323
I ran a number of TC tests, almost all are passing apart from 3 that
are failing, but the failures don't seem to be related to the change
and also fail in other runs.
Cheers,
Jens
On Tue, Jul 26, 2016 at 12:40 AM, jayho wrote:
Igniters,
This applies equally to Java and .NET:
Writing XML configuration in not easy or fun. I've seen lots of questions
on how to configure things in XML.
Spring syntax is cumbersome even when you get used to it.
On the other hand, setting IgniteConfiguration properties directly in Java
or C#
Vladimir Ozerov created IGNITE-3579:
---
Summary: Message type should be short.
Key: IGNITE-3579
URL: https://issues.apache.org/jira/browse/IGNITE-3579
Project: Ignite
Issue Type: Task
43 matches
Mail list logo
