Hi guys,
I noticed that IgniteMultimap waits too long to be implemented and I
decided to pick it up :-)
For now I want to bring to community up a draft version for IgniteMultimap
interface. Will appreciate any feedback and once it's fine I will start its
implementation
package org.apache.ignite
There is one more use case where several types per cache can be useful (I
know that it's utilized by some of our users). The use case is the
following: transactional updates with write-behind and foreign key
constraints on the database. In case data within transaction is collocated
and all types ar
GitHub user pperalta opened a pull request:
https://github.com/apache/ignite/pull/952
IGNITE-3678: Test for partition distribution
This submission includes a test that will assert the even and safe
distribution of partitions when server nodes are forcibly killed.
Additional
On Thu, Aug 11, 2016 at 7:25 AM, Sergey Kozlov wrote:
> Alexey
>
> You're right. Of course I meant growth of caches number.
>
> I see a few points here:
>
> 1. If a grid used by various applications the cache names may overlap (like
> "accounts") and the application needs to use prefixed names an
Patrick Peralta created IGNITE-3678:
---
Summary: Test for partition distribution functionality
Key: IGNITE-3678
URL: https://issues.apache.org/jira/browse/IGNITE-3678
Project: Ignite
Issue Ty
Alexey
You're right. Of course I meant growth of caches number.
I see a few points here:
1. If a grid used by various applications the cache names may overlap (like
"accounts") and the application needs to use prefixed names and etc.
2. For clear or destory caches I need to know their names (or
GitHub user ntikhonov opened a pull request:
https://github.com/apache/ignite/pull/951
Ignite 2559
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-2559
Alternatively you can review and apply these c
Sergey, I belive you mean "increase" instead of "reduce"?
How grouping will help?
To do some operation, for example, clear on group of cashes at once?
11 Авг 2016 г. 22:06 пользователь "Sergey Kozlov"
написал:
> I mean not only SQL features for caches. Single type per cache definitely
> reduces
GitHub user ptupitsyn opened a pull request:
https://github.com/apache/ignite/pull/950
IGNITE-3095 .NET: Reference NUnit via NuGet instead of predefined folder
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ptupitsyn/ignite igni
I mean not only SQL features for caches. Single type per cache definitely
reduces number of caches for regular user and grouping caches will help to
manage caches in grid.
On Thu, Aug 11, 2016 at 5:41 PM, Sergi Vladykin
wrote:
> I'm aware of this issue. My plan was to allow setting the same sche
I'm aware of this issue. My plan was to allow setting the same schema name
to different caches using CacheConfiguration.setSqlSchema(...). This way we
will have separate caches but from SQL point of view respective tables will
reside in the same schema. No need to introduce new concepts.
Sergi
2
HI
Due to approach to disable to store more than one type per cache the cache
use becomes similar the table use for databases.
So I suppose would be good to introduce a database/schema-similar concept
for caches. It may be implemented as a non-default behavior for backward
compatibility.
On Sat,
GitHub user EdShangGG opened a pull request:
https://github.com/apache/ignite/pull/949
Ignite 2546
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/EdShangGG/ignite ignite-2546
Alternatively you can review and apply these changes
Vladimir Ozerov created IGNITE-3677:
---
Summary: IGFS: Add supported options feature to the secondary FS.
Key: IGNITE-3677
URL: https://issues.apache.org/jira/browse/IGNITE-3677
Project: Ignite
Thanks Denis, done.
On Thu, Aug 11, 2016 at 2:43 AM, Denis Magda wrote:
> Pavel, here is the ticket
> https://issues.apache.org/jira/browse/IGNITE-3675
>
> —
> Denis
>
> On Aug 9, 2016, at 11:40 PM, Sergi Vladykin
> wrote:
>
> Yes, it is a good idea, because I think in 2.0 we will disallow havi
GitHub user tledkov-gridgain opened a pull request:
https://github.com/apache/ignite/pull/948
IGNITE-3676 Fix the test IgfsDualAbstractSelfTest#testOpenNoPrefetch
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ig
Github user tledkov-gridgain closed the pull request at:
https://github.com/apache/ignite/pull/947
---
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 featu
GitHub user tledkov-gridgain opened a pull request:
https://github.com/apache/ignite/pull/947
Ignite 3676
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-3676
Alternatively you can review and apply
Taras Ledkov created IGNITE-3676:
Summary: Fix the test IgfsDualAbstractSelfTest#testOpenNoPrefetch
Key: IGNITE-3676
URL: https://issues.apache.org/jira/browse/IGNITE-3676
Project: Ignite
Iss
GitHub user AMashenkov opened a pull request:
https://github.com/apache/ignite/pull/946
Ignite 2560
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-2560
Alternatively you can review and apply these
Great blog post, Denis!
One nitpick: do not use periods in the headings :)
I'll update the .NET docs shortly.
Pavel.
On Thu, Aug 11, 2016 at 2:31 AM, Denis Magda wrote:
> Igniters,
>
> As most of you know recently we have released Ignite 1.7.0 that has the
> distributed joins functionality. I
21 matches
Mail list logo