Hi, Pavel.
I've found a bug in BinaryTupleComparator, which is used by Indexes,
that byte[] comparison is non-conformed with SQL standard.
The fix is ready [1] and merged to master.
The fix breaks ordering in Indexes for byte strings that affects binary
compatibility between versions.
Can we add
Hello Igniters,
Please, take a look at the proposal for Ignite 3: IEP-134 SQL-schema
support [1].
[1]
https://cwiki.apache.org/confluence/display/IGNITE/IEP-134+SQL-schema+Support
--
Best regards,
Andrey V. Mashenkov
HI,
I have a few questions.
Assume, a user creates table via key-value annotated classes:
ignite.catalog().create(PojoKey.class, PojoValue.class).execute();
1. What is the difference between having @Table annotation on the
key class or on the value class?
When both classes are annotated, which on
ow some teams, who do. At the last Ignite Summit we had a talk
> >> featuring Ml module (from the Groovy community).
> >> Anyway, We need here the module maintainer opinion
> >> + Alex
> >>
> >> On Wed, Aug 9, 2023 at 3:38 PM Andrey Mashenkov <
> &
-1 for removal.
0 for relocation
imho, TC resources and module size aren't good arguments for
removal/moving.
ML tests could be run nightly.
ML module contains few integrations (with TensorFlow and other), these
optional integrations are wighty and could be moved to extension,
but core functionali
Hi,
Please review "IEP-108 Change column type” proposal
https://cwiki.apache.org/confluence/display/IGNITE/IEP-108+Change+column+type
--
Best regards,
Andrey V. Mashenkov
Hi,
Good catch!
I've looked at the PR and left a few comments.
On Wed, Mar 8, 2023 at 12:08 PM Jian Chen wrote:
> Hi Igniters,
>
> Could someone help to review the PR
> https://github.com/apache/ignite/pull/10579 ?
>
> It's a minor fix for translation about the user get table failed through
>
Hi Ivan,
I'm ok to add reactive-streams.jar, because it contains just interfaces
that 1:1 java-flow API and FlowAdapter to convert JDK <-> ReactiveStreams
interfaces.
The interfaces available in JDK >= 9 java.util.concurrent.Flow, are 1:1
> semantically equivalent to their respective Reactive Str
Hi Igniters,
I agree with Slava, we have to provide alternative ways for users before
dropping a feature that just worked.
A user may use some feature for a long time without any issues, so, this is
why there is no mention in chats/mails.
I mean here, the feature is not only the whole visor comman
Congratulations, Taras!
On Sat, Aug 20, 2022 at 12:18 AM Dmitriy Pavlov wrote:
> Hi Igniters!
>
> The Project Management Committee (PMC) for Apache Ignite has invited
> Taras Ledkov to become a member of the PMC and we are pleased to
> announce that he has accepted.
>
> Taras is a veteran commit
Congratulations, Slava!
On Wed, Aug 17, 2022 at 5:35 PM Kseniya Romanova
wrote:
> Hi Igniters!
>
> The Project Management Committee (PMC) for Apache Ignite has invited
> Vyacheslav Koptilin to become a member of the PMC and we are pleased to
> announce that he has accepted.
>
> Vyacheslav is a v
n the topic?
[1] https://issues.apache.org/jira/browse/IGNITE-15212
[2] https://issues.apache.org/jira/browse/IGNITE-16952
On Tue, Apr 6, 2021 at 4:23 PM Andrey Mashenkov
wrote:
> Hi Taras.
>
> 1. AFAIK, only Thin clients will be available in 3.0.
> However, yes, Native JDBC API is sti
Hi Sameiksha,
Ilya is right, upgrading H2 dependency is no longer possible.
You can try to shade H2 dependency with maven-shade-plugin and rebuild the
Ignite from sources.
On Wed, Mar 16, 2022 at 10:20 PM Ilya Kasnacheev
wrote:
> Hello!
>
> Later version of H2 removed some of APIs which Ignite
Hi Igniters,
I've created a ticket [1] with the PR [2] where wrote 3 tests for some
scenarios that lead to index corruption.
The scenarios are described in detail in the PR, so, you may look at a code
for better understanding.
Please, feel free to create a separate ticket for fixing any of the ne
Alex,
it would be great to release a new SQL engine in 2.13 as an
experimental feature.
Is this [1] a full scope of the tickets that MUST be resolved before the
engine could be merged?
I think we have to add instructions to the readme file on how to turn a new
SQL engine on.
Also, I don't like th
Congrats, Vlad!
ср, 22 дек. 2021 г., 20:23 Valentin Kulichenko <
valentin.kuliche...@gmail.com>:
> The Apache Ignite Project Management Committee (PMC) has invited Vladislav
> Pyatkov to become a new committer and are happy to announce that he has
> accepted.
>
> Vladislav is a veteran of the Apa
it. Based on the results of the
> > discussion, I have filed a ticket [1].
> > I will try to investigate it.
> >
> > [1] - https://issues.apache.org/jira/browse/IGNITE-16157
> >
> > On 16.12.2021 20:11, Ivan Daschinsky wrote:
> > > Andrey,
Guys,
I like the idea with a flag, but for a different purpose.
I think it is easy to detect the issue (using the flag) when
metastorage was created on a new version with a fixed charset, or on an
older version with the user-defined default.
Regarding the flag, we can choose a new strategy forcing
Ivan,
Great job. PR looks good.
This allocator in interleaved mode and passing `-XX:+UseNUMA` flag to jvm
> show promising results on yardstick benches. Technically, G1 is not a numa
> aware collector for java versions less than 14, but allocation of heap in
> interleaved mode shows good results
Hi Maxim,
I like the idea, the IEP looks very useful.
However, I agree with Nikolay on this
>
> Don’t think we should rely on auto scan class path capabilities.
> 1. How this automatic scanner will distinguish ignite class from
> user class if they both in node class path and same packag
+1
вт, 5 окт. 2021 г., 13:33 Юрий :
> +1
>
> вт, 5 окт. 2021 г. в 02:52, Valentin Kulichenko <
> valentin.kuliche...@gmail.com>:
>
> > Hello Community,
> >
> > As discussed in [1], I would like to propose the creation of a separate
> > Jira project and Confluence space for Ignite 3.
> >
> > Ignit
Huge +1.
сб, 18 сент. 2021 г., 04:22 Valentin Kulichenko <
valentin.kuliche...@gmail.com>:
> Igniters,
>
> I think it's clear to all of us that Ignite 2.x and 3.x will coexist for a
> while. They are developed in separate Git repos, but we still accumulate
> the tickets for both versions in the s
Actually, Index Query API suite is not part of RunAll.
Let's fix this.
On Wed, Sep 15, 2021 at 5:12 PM Maksim Timonin
wrote:
> Hi, Petr!
>
> I closed the ticket, Anton Vinogradov (thanks!) helped me and created the
> suite fast. It successfully ran.
>
>
> https://ci.ignite.apache.org/buildConfi
based on our enumeration.
This will require an order guarantee from the protocol, that the results
are returned in the same order the keys are passed into the request.
On Mon, Sep 13, 2021 at 3:30 PM Andrey Mashenkov
wrote:
> Pavel,
>
> 1. Comparator introduces an ordered relation, bu
Pavel,
1. Comparator introduces an ordered relation, but we need only equality
(e.g. Objects.deepEquals).
Ok, we can implement some orders for basic types adding complexity to cast
and compare for all the values.
2. Hashcode calculation will require iterating over all the columns. Most
likely ite
-1
Supporting few copy-pasted methods is much easier than support dependencies
compatibility.
On Tue, Sep 7, 2021 at 7:42 PM Zhenya Stanilovsky
wrote:
>
> Aleksandr, thanks for this activity.
> -1 from my side, all my decisions are in linked discussion.
>
> >Dear Igniters,
> >
> >In this thread
.@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Zhenya,
> > > > > > >
> > > > > > > > But there is no restrictions from running ignite server nodes
> > from
> > &
@Ivan Daschinsky
By the way, users are forced to specify index condition in order that match
column order in the index.
On Thu, Aug 26, 2021 at 3:24 PM Ivan Daschinsky wrote:
> I am against to make user write index name. It is quite simple and
> straightforward algorithm to match index to fiel
Congrats, Petr!
On Thu, Aug 19, 2021 at 12:58 PM Dmitry Pavlov wrote:
> Hello Ignite community,
>
> The Project Management Committee (PMC) for Apache Ignite
> has invited Petr Ivanov (vveider) to become a committer and we are pleased
> to announce that he has accepted.
>
> Petr is community vete
-1
It is sad to say -1, as Guava has very useful stuff and it looks easier to
add it as a dependency rather than copy-paste a code. My concerns are: 1.
Original Bytecode module depends on 26.0-jre Calcite depends on 29.0-jre We
maybe will use some other version. A user might want to use one more
ve
Congratulations Zhenya!
On Fri, Jul 30, 2021 at 12:06 AM Maxim Muzafarov wrote:
> The Project Management Committee (PMC) for Apache Ignite has invited
> Zhenya Stanilovsky to become a committer and we are pleased to announce
> that
> he has accepted.
>
> For the last few years, Zhenya made a lo
Atri.
I think Ilya means IgniteCombinedSchedulerProcessor that delegates calls to
2 different Scheduler implementations.
And the logic may not be enough clear for a user.
1. You added a new mandatory dependency on Quartz.
We are trying to avoid this as much as possible, because this may lead to
t
hort summary)
> and
> > further POC and implementation.
> > That's a big deal, so let's discuss what could be done here.
> >
> > On Fri, Jul 23, 2021 at 12:58 PM Atri Sharma wrote:
> >
> > > I am actually happy to drive the feature for Ignite 3. FT
alentin Kulichenko <
> > > valentin.kuliche...@gmail.com> wrote:
> > >
> > > > Atri,
> > > >
> > > > Sure, go ahead. Let's put the ideas on paper and have a discussion.
> > > >
> > > > -Val
> > > >
for me and I think Ignite users will benefit from it
> greatly.
>
> If it makes sense to be focusing on Ignite 3 for this capability, I am
> eager to contribute there and lead the development.
>
> Please share your thoughts.
>
> On Fri, Jul 23, 2021 at 3:21 PM Andrey Ma
Hi Atri,
All the Jira tickets we have on the Full-text search (FTS) thing are
targeted to Ignite 2.
AFAIK, we want, but we have NOT committed to FTS support in Ignite 3, yet.
By the way, we are getting requests for this thing from the user side, and
definitely,
FTS would be a valuable feature for
ere T1.key in
(TextQueryFunction("text_query_string"))",
where "TextQueryFunction" is a custom SQL function that might be able to
access some static method or local Ignite service or whatever, then
will this work for you?
On Fri, Jul 23, 2021 at 1:10 AM Andrey Mashenkov
wrote:
> Hi C
Hi Courtney,
Thanks for your feedback.
I've gone through the questions and have no the whole picture of your use
case.
Would you please clarify how you exactly use the Ignite? what are the
integration points?
and maybe share some experience with using Ignite SPIs?
We'll keep the information in m
Hi guys,
I think updateHeartBeat() method was misused in the future listener and
this must be fixed.
Actually, GridWorker.heartbeatTs Javadoc says that field is updated by the
worker itself.
It is consistent with WorkProgressDispatcher.updateHearbeat() javadoc,
which said "Notifying dispatcher th
stated in the javadoc in the PR.
>
> Andrey,
>
> Then using "runInTransaction", lack of commit will cause a transaction to
> rollback automatically.
>
> There is no need for a "close" method, it just adds confusion.
>
>
> ср, 14 июл. 2021 г. в 11:37, Andrey
Agree with Ivan.
Method runInTransaction() should try to finish the transaction if the user
forgot to commit one.
I guess it might be a common mistake among new users.
Also, I suggest to extent all table projections for better UX.
Let's allow
table.kvView().withTx(tx)
to user may cache kvVew
>
> I suppose that we should describe this more verbose and explicit. I
> nevertheless suggest to also consider writing values this way:
> - arr of fields names (if name is missed, corresponding field is nil)
> - arr of rows (row as array, length equal to fields array)
Ivan,
I think GET and PUT o
Hi Pavel,
2. Schema and its version are internal things and shouldn't be exposed,
otherwise, eventually, it will lead to the user will manage schemas
manually on his side for some purposes.
This will force us to bother about interfaces/contracts and compatibility
aspects in the future with uncerta
this step it will be
> > > possible to configure TC in order to use this configuration.
> > > 2. Configure TC.
> > > 3. Commit a non-empty checkstyle config, but all modules should be
> > > excluded from checking on this step.
> > > 4. For each module create a
Ivan, thankd for clarification.
Binarilizable interface forces user to write serialization code. We can
support this or similar interface.
But I'd like Ignite has some default serializer in addition. It can be also
useful e.g. in compute for param and result serialization.
BinaryObjectBuider requ
> чт, 17 июн. 2021 г., 19:55 Andrey Mashenkov :
>
> > Hi Pavel,
> >
> > What you suggest looks promising: arbitrary object graph and platform
> > independence aspects in particular.
> >
> > In IEP-54 we support only flat objects and only some standard types
Hi Pavel,
What you suggest looks promising: arbitrary object graph and platform
independence aspects in particular.
In IEP-54 we support only flat objects and only some standard types and
assume inner objects of custom types will be serialized to byte[] somehow
and their schema will not be manage
> Is it really need to use thread-locals for user threads? - probably not.
> I'm not sure if there is any problem at all. As soon as we want to have
> async API everywhere, out code should not be executed in user thread
>
> чт, 8 апр. 2021 г. в 13:37, Andrey Mashenkov :
>
&
Hi Igniters,
I and Alex Scherbakov had a discussion on how we could write rows in a more
compact way.
Many thanks to Alex for his ideas and critics.
So, in a long-read below I want to share some thoughts.
Motivation.
In Ignite 3.0 we will have versioned schema and most of the meta info will
be s
Hi Atri,
You've added a new property to a base TcpDiscoveryIpFinder interface.
Actually, the only Azure IpFinder uses this setting, but the others.
This behavior may confuse the users.
Would you mind either making regexp filter setting a part of Azure IpFinder
only or fix other IpFinders as well?
т, 16 апр. 2021 г. в 16:30, Alexei Scherbakov <
> alexey.scherbak...@gmail.com
> >:
>
> >
> >
> > чт, 15 апр. 2021 г. в 18:21, Andrey Mashenkov <
> andrey.mashen...@gmail.com
> > >:
> >
> >> Hi Alexey,
> >> I like the idea.
&
avadocs for all non-test classes including
internal (but their members) as well.
On Mon, Apr 19, 2021 at 6:37 PM Andrey Mashenkov
wrote:
> Alexey,
>
> These are bad examples and unfortunately, most of the Ignite code doesn't
> look self-descriptive.
> (Do you feel the differ
de readability during code review. Main motivation here is
> > that ubiquitous javadocs did not work well in ignite-2 and I believe
> > it would not in ignite-3.
> >
> > 2021-04-19 13:30 GMT+03:00, Andrey Mashenkov >:
> > > Hi Igniters,
> > >
> > >
Hi Igniters,
We use JDK Javadoc tool to validate javadocs on TC (Javadoc suite) in
Ignite 2 and now in Ignite 3.
A javadoc tool is designed for javadoc site generation that also performs
some basic checks and markup validation,
but has nothing to do with javadoc styles.
I've found maven-checkstyl
Andrey Mashenkov created IGNITE-14591:
-
Summary: Add Javadoc rules to maven checkstyle plugin.
Key: IGNITE-14591
URL: https://issues.apache.org/jira/browse/IGNITE-14591
Project: Ignite
Andrey Mashenkov created IGNITE-14571:
-
Summary: Add RELEASE.md file to project.
Key: IGNITE-14571
URL: https://issues.apache.org/jira/browse/IGNITE-14571
Project: Ignite
Issue Type
Andrey Mashenkov created IGNITE-14563:
-
Summary: Fix javadoc in Runner module.
Key: IGNITE-14563
URL: https://issues.apache.org/jira/browse/IGNITE-14563
Project: Ignite
Issue Type: Bug
Andrey Mashenkov created IGNITE-14562:
-
Summary: Fix javadoc in Network module.
Key: IGNITE-14562
URL: https://issues.apache.org/jira/browse/IGNITE-14562
Project: Ignite
Issue Type: Bug
Andrey Mashenkov created IGNITE-14561:
-
Summary: Fix javadoc in Configuration module.
Key: IGNITE-14561
URL: https://issues.apache.org/jira/browse/IGNITE-14561
Project: Ignite
Issue Type
Andrey Mashenkov created IGNITE-14560:
-
Summary: Fix javadoc in CLI module.
Key: IGNITE-14560
URL: https://issues.apache.org/jira/browse/IGNITE-14560
Project: Ignite
Issue Type: Bug
Andrey Mashenkov created IGNITE-14559:
-
Summary: Fix javadoc in schema and table modules
Key: IGNITE-14559
URL: https://issues.apache.org/jira/browse/IGNITE-14559
Project: Ignite
Issue
Hi Alexey,
I like the idea.
1.
> TBL-0001 is a *string representation* of the error. It is built from 2
> byte scope id (mapped to name TBL) and 2 byte number (0001). Both
> internally packed in int. No any kind of parsing will be necessary to read
> scope/category.
I think Alexey mean if it w
Andrey Mashenkov created IGNITE-14557:
-
Summary: Imrove row layout.
Key: IGNITE-14557
URL: https://issues.apache.org/jira/browse/IGNITE-14557
Project: Ignite
Issue Type: Improvement
Andrey Mashenkov created IGNITE-14556:
-
Summary: Add Tuple validation.
Key: IGNITE-14556
URL: https://issues.apache.org/jira/browse/IGNITE-14556
Project: Ignite
Issue Type: Improvement
Ivan, congrats!
On Tue, Apr 13, 2021 at 11:42 AM Alexei Scherbakov <
alexey.scherbak...@gmail.com> wrote:
> Ivan, great work.
>
> вт, 13 апр. 2021 г. в 10:53, Ivan Pavlukhin :
>
> > Ivan, congrats!
> >
> > 2021-04-13 9:41 GMT+03:00, Nikolay Izhikov :
> > > Congrats! Well deserved.
> > >
> > >> 13
derstand this param helps to control how much
>> returned row is filled. Then we can use it to return an object that
>> contains only basic info - link, pageAddr, offset. Then predicate operation
>> will be applied on the higher level on a cursor returned by a tree (like
>>
Andrey Mashenkov created IGNITE-14514:
-
Summary: Drop legacy interfaces.
Key: IGNITE-14514
URL: https://issues.apache.org/jira/browse/IGNITE-14514
Project: Ignite
Issue Type: Improvement
Andrey Mashenkov created IGNITE-14512:
-
Summary: General purpose DirectMemoryRegion.
Key: IGNITE-14512
URL: https://issues.apache.org/jira/browse/IGNITE-14512
Project: Ignite
Issue Type
Also, with the suggested approach,
we should avoid indirectly usage of ForkJoinPool internally or set our own
pool instance explicitly when using reactive things.
On Thu, Apr 8, 2021 at 1:33 PM Andrey Mashenkov
wrote:
> Alexey,
>
> I've made a PR for logger [1].
> Seems, we w
e set while entering ignite context (for
> example, by calling public API method)
> * Factory method is not necessary, because we already have a proxy object -
> LogWrapper, hiding internal implementation.
>
>
>
>
>
>
>
> ср, 7 апр. 2021 г. в 18:39, Andrey Mashenkov
suggested usage is something like:
> >
> > private static LogWrapper LOG = new LogWrapper(MyClass.class);
> >
> > [1]
> >
> >
> https://github.com/gridgain/apache-ignite-3/blob/9acb050a6a6a601ead849797293a1d0ad48ab9e0/modules/core/src/main/java/org/apache/ignite/lang/L
nly if index is inlined properly (even a part
> of rows aren't inlined due to varlen - it still can be faster then make a
> ScanQuery);
> 3. Ignite creates a proxy object that is filled with objects that are
> inlined. If a user tries to access a field that isn't inlined
Andrey Mashenkov created IGNITE-14500:
-
Summary: Add table exceptions to public API.
Key: IGNITE-14500
URL: https://issues.apache.org/jira/browse/IGNITE-14500
Project: Ignite
Issue Type
Hi Maksim,
Nice idea, I'd like to see this feature in Ignite.
The motivation is clear to me, it would be nice to have fast scans and omit
SQL overhead on planning, parsing and etc in some simple use-cases.
I've left few minor comments to the IEP, but I have the next questions
which answer I faile
Hi Taras.
1. AFAIK, only Thin clients will be available in 3.0.
However, yes, Native JDBC API is still "must have" on servers.
2. We won't have other projects in dependencies if possible. Unless we/they
are Jigsaw compatible though.
2.1 I think it makes sense to be an R2DBC-compatible as it is
Andrey Mashenkov created IGNITE-14488:
-
Summary: Implement invoke operations for table views.
Key: IGNITE-14488
URL: https://issues.apache.org/jira/browse/IGNITE-14488
Project: Ignite
Andrey Mashenkov created IGNITE-14487:
-
Summary: Implement KeyValye binary view.
Key: IGNITE-14487
URL: https://issues.apache.org/jira/browse/IGNITE-14487
Project: Ignite
Issue Type
Andrey Mashenkov created IGNITE-14486:
-
Summary: Table binary view implementation.
Key: IGNITE-14486
URL: https://issues.apache.org/jira/browse/IGNITE-14486
Project: Ignite
Issue Type
Andrey Mashenkov created IGNITE-14484:
-
Summary: Implement RecordView API.
Key: IGNITE-14484
URL: https://issues.apache.org/jira/browse/IGNITE-14484
Project: Ignite
Issue Type
Andrey Mashenkov created IGNITE-14479:
-
Summary: Add column default values support.
Key: IGNITE-14479
URL: https://issues.apache.org/jira/browse/IGNITE-14479
Project: Ignite
Issue Type
treams.org/reactive-streams-1.0.3-javadoc/org/reactivestreams/FlowAdapters.html
>
> 2021-04-02 12:00 GMT+03:00, Andrey Mashenkov :
> > Ivan,
> > thanks for the link. I think, now I've got what you mean.
> >
> > I don't think we want to have any framework as a depende
Andrey Mashenkov created IGNITE-14467:
-
Summary: Ignite Compute service.
Key: IGNITE-14467
URL: https://issues.apache.org/jira/browse/IGNITE-14467
Project: Ignite
Issue Type: New Feature
ingular reactive abstractions as well.
> E.g. [1].
>
> [1]
> https://projectreactor.io/docs/core/release/api/reactor/core/publisher/Mono.html
>
> 2021-04-01 12:33 GMT+03:00, Andrey Mashenkov :
> > Val,
> > I just complain JDK CompletableFuture itself is not ideal, but a
> CompletableFuture.
>
> [1] https://github.com/reactive-streams/reactive-streams-jvm#specification
>
> 2021-03-31 21:30 GMT+03:00, Valentin Kulichenko <
> valentin.kuliche...@gmail.com>:
> > Hi Andrey,
> >
> > Please see below.
> >
> > -V
; > > > longer
> > > > > > needs to execute the task?
> > > > > > > If the task is currently running, does it need to be canceled?
> > > > > >
> > > > > > Yes, this case looks like Ignite should cancel computatio
ture instead, which can
> be completed in 3-rd party plugin by mistake?
>
> If exchange futures or partition release futures can be returned to 3-rd
> party plugin by mistake, it is poor encapsulation.
> And if it will be IgniteFuter rather than CompletedFuture, anyway, this can
> harm.
>
ults as well. E.g. premature completion in
> > >> case when a result is no longer needed is possible usage.
> > >>
> > >> Also I thinkg it might be a good time to ponder about Future/Promise
> > >> APIs in general. Why such API is our choice? Can we
Agree with package and module naming.
I just thought that
Service is a self-suffucient component and provides high-level API to
user/other components/services (e.g. RaftService to TableService).
Manager is internal component - a logical brick of the Service (e.g.
RaftGroupManager or TableSchemaMan
Forgot to attach a link to the PR with an example [1].
[1] https://github.com/apache/ignite-3/pull/59
On Fri, Mar 26, 2021 at 4:03 PM Andrey Mashenkov
wrote:
> Hi Igniters,
>
> In almost every new task we faced the problem of what logger has to be
> used: JUL. log4J or any else.
&
Hi Igniters,
In almost every new task we faced the problem of what logger has to be
used: JUL. log4J or any else.
Since JDK 9 there is a System.Logger which interface looks acceptable for
use,
excepts maybe some usability issues like method signatures.
LogLevel is passed as a mandatory argument,
Andrey Mashenkov created IGNITE-14430:
-
Summary: Common logger interface.
Key: IGNITE-14430
URL: https://issues.apache.org/jira/browse/IGNITE-14430
Project: Ignite
Issue Type
;>> Generally, CompletableFuture is a much better option, because it's
> >>> standard. But we need to make sure it actually fits our needs and
> doesn't
> >>> do more harm than good.
> >>>
> >>> -Val
> >>>
> >>> O
Hi Igniters,
I'd like to start a discussion about replacing our custom IgniteFuture
class with CompletableFuture - existed JDK class
or rework it's implementation (like some other products done) to a
composition of CompletionStage and Future interfaces.
or maybe other option if you have any ideas.
Hi Maksim,
Do you mean MVCC will not work at all or MVCC will not support indices
after your changes?
Anyway, this looks like a major change and may be too harmful for the minor
version (10.1).
Before break MVCC index (or MVCC mode) we should force the user first to
drop all MVCC indices (or even
Andrey Mashenkov created IGNITE-14388:
-
Summary: Add affinity key support.
Key: IGNITE-14388
URL: https://issues.apache.org/jira/browse/IGNITE-14388
Project: Ignite
Issue Type
Andrey Mashenkov created IGNITE-14342:
-
Summary: Extend Tuple interface with ordered field access.
Key: IGNITE-14342
URL: https://issues.apache.org/jira/browse/IGNITE-14342
Project: Ignite
Andrey Mashenkov created IGNITE-14330:
-
Summary: Implement binary table views API.
Key: IGNITE-14330
URL: https://issues.apache.org/jira/browse/IGNITE-14330
Project: Ignite
Issue Type
27;t find any async methods,
> can you please check if the changes are pushed?
>
> On Tue, Mar 16, 2021 at 10:06 PM Andrey Mashenkov <
> andrey.mashen...@gmail.com> wrote:
>
> > Pavel, good point.
> > Thanks. I've added async methods.
> >
>
Pavel, good point.
Thanks. I've added async methods.
On Fri, Mar 12, 2021 at 2:29 PM Pavel Tupitsyn wrote:
> Andrey,
>
> What about corresponding async APIs, do we add them now or later?
>
> On Thu, Mar 11, 2021 at 8:11 PM Andrey Mashenkov <
> andrey.mashen...@gm
Andrey Mashenkov created IGNITE-14316:
-
Summary: BinaryObject API
Key: IGNITE-14316
URL: https://issues.apache.org/jira/browse/IGNITE-14316
Project: Ignite
Issue Type: Improvement
1 - 100 of 328 matches
Mail list logo
