e/ignite-3/pull/2
On Wed, Jan 20, 2021 at 6:05 PM Andrey Mashenkov
wrote:
>
> I've updated a PR regarding your feedback [1].
>
> [1] https://github.com/apache/ignite-3/pull/2
>
> On Mon, Jan 11, 2021 at 10:58 AM Alexey Goncharuk <
> alexey.goncha...@gmail.com> wro
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
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.
> >
>
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
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.
;>> 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,
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,
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.
&
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
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
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.
>
; > > > 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
> 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
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
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
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
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
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
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
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
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
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
>>
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
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
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
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,
> > >
> > >
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
т, 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.
&
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?
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
> 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 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
> чт, 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
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
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
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
>
> 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
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
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
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
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
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 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
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
alentin Kulichenko <
> > > valentin.kuliche...@gmail.com> wrote:
> > >
> > > > Atri,
> > > >
> > > > Sure, go ahead. Let's put the ideas on paper and have a discussion.
> > > >
> > > > -Val
> > > >
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
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
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
-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
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
@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
.@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Zhenya,
> > > > > > >
> > > > > > > > But there is no restrictions from running ignite server nodes
> > from
> > &
-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
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
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
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
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
+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
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
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
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
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,
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
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
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
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
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
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
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
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
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,
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
>
ll response records to the
> > > > > client-node
> > > > > > > > and it may contain ~thousands, ~hundred thousands records.
> > > > > > > > Event if we need only first 10-100. Again, all the results
> are
> > &g
> What will be the next steps in order to merge in?
>
> Y.
>
> чт, 3 жовт. 2019 о 17:47 Andrey Mashenkov
> пише:
>
> > Yuri,
> >
> > I've done with review.
> > No crime found, but trivial compatibility bug.
> >
> > On Thu, Oct 3, 201
12189
>>
>> Could you please proceed with PR merge ?
>>
>> BR,
>> Yuriy Shuliha
>>
>> ср, 9 жовт. 2019 о 12:52 Andrey Mashenkov
>> пише:
>>
>> > Hi Yuri,
>> >
>> > To get access to TC Bot you should regi
+ 1 Dmitry Pavlov (non-binding)
On Wed, Oct 30, 2019 at 3:19 PM Zhenya Stanilovsky
wrote:
>
> +1 for Nikolay Izhikov.
>
>
> >Среда, 30 октября 2019, 15:16 +03:00 от Alexey Zinoviev <
> zaleslaw@gmail.com>:
> >
> >+1 Dmitry Pavlov
> >
> >ср, 30 окт. 2019 г. в 13:50, Nikolay Izhikov < nizhi...
+1 to Alexey's concerns.
Local SQL query mode is error prone, as a query executes over non-predicted
set of partitions.
Using local mode with deep SQL execution model understanding will lead to
inconsistent result.
Just imagine if we add a note to documentation that "in case of local SQL
user res
Contrats, Alexey!
On Thu, Dec 12, 2019 at 4:46 PM Dmitriy Pavlov wrote:
> Hello Ignite Community,
>
>
>
> The Project Management Committee (PMC) for Apache Ignite has invited Alexey
> Zinoviev (zaleslaw) to become a PMC member and we are pleased to announce
> that he has accepted.
>
>
>
> Alexey
Congrats, Ivan!
On Thu, Dec 12, 2019 at 5:41 PM Dmitriy Pavlov wrote:
> Hello Ignite Community,
>
>
>
> The Project Management Committee (PMC) for Apache Ignite has invited Ivan
> Pavlukhin to become a PMC member and we are pleased to announce that he has
> accepted.
>
>
>
> We appreciate Ivan’s
Hi Igniters,
Let me share some thoughts. Abstractly.
1. @Experimental API. When user see API marked as experimental usually it
is a red flag for using such API in prod
and also he can't count the API stability:
- API itself if not stable and one can have compilation issues with next
versions at l
-1 Prohibit.
We must not deprecate old API without have a new stable well-documented
alternative and a way to migrate to new one.
On Mon, Feb 10, 2020 at 11:02 AM Alexey Goncharuk
wrote:
> Dear Apache Ignite community,
>
> We would like to conduct a formal vote on the subject of whether to all
Congratulations, Slava!
вт, 18 февр. 2020 г., 22:20 Dmitriy Pavlov :
> Hello Ignite Community,
>
> The Project Management Committee (PMC) for Apache Ignite has invited
> Vyacheslav Koptilin to become a committer and we are pleased to announce
> that he has accepted.
>
> Vyacheslav investigated an
Write lock is an exclusive lock and no other threads can obtain read or
write lock while current thread holding write lock.
Why you think checking for current thread is lock-owner is not atomic?
A thread that already holds a write lock has no needs to obtain read locks
unless it releases the write
Maxim,
Good idea. I'd add a license check as well.
On Tue, Apr 14, 2020 at 2:14 AM Maxim Muzafarov wrote:
> Igniters,
>
> It's really `must-have` feature for me to enable Apache Ignite
> pull-request status checks on GitHub. Currently we don't have any of
> them. The most obvious check for each
Congrats, Taras!
вт, 12 мая 2020 г., 19:09 Dmitriy Pavlov :
> Hello Ignite Community,
>
>
>
> The Project Management Committee (PMC) for Apache Ignite has invited Taras
> Ledkov to become a committer and we are pleased to announce that he has
> accepted.
>
>
> Taras is an Ignite SQL veteran who k
+1
On Mon, May 18, 2020 at 9:19 PM Ivan Rakov wrote:
> Hi Igniters,
>
> I have a very simple proposal. Let's set default TX timeout to 5 minutes
> (right now it's 0 = no timeout).
> Pros:
> 1. Deadlock detection procedure is triggered on timeout. In case user will
> get into key-level deadlock,
Konstantin,
+1
I've just found that I should waste my time fixing styles in user code that
(may be) reproduce some bug, just to validate the bug or fix provided by
the user.
I'm ok with the idea to block commits with style errors to master branch,
but not for other branches\PR.
Can anybody expla
fail the build on code style errors.
> Code style errors == compile errors for me.
>
> > 8 июня 2020 г., в 16:40, Andrey Mashenkov
> написал(а):
> >
> > Konstantin,
> >
> > +1
> >
> > I've just found that I should waste my time fixing styles in us
good then we should use them in daily coding,
> isn’t it?
>
> Anyway, I think forcing code style rules as early as we can is a good
> thing.
> Some open-source projects(Kafka, for example) forces code style rules even
> on a local test run.
>
> > 8 июня 2020 г., в 17:22
Congratulations, Sergey.
пт, 17 июл. 2020 г., 15:06 Вячеслав Коптилин :
> Hi,
>
> Well deserved! Keep it up, Sergey!
>
> Thanks,
> S.
>
> пт, 17 июл. 2020 г. в 14:36, Ivan Pavlukhin :
>
> > Sergey, congratulations!
> >
> > 2020-07-17 14:25 GMT+03:00, Petr Ivanov :
> > > Congratulations!
> > >
> >
Hi Ilya,
Thanks for the notice.
I've reviewed these PRs. They all look good, but I have few questions.
Please, take a look.
On Thu, Oct 1, 2020 at 1:06 PM Ilya Kasnacheev
wrote:
> Hello fellow developers!
>
> It seems that we have problems with our review process currently, which
> wasn't there
Hi, Igniters.
* AFAIU, we need a new repo if we want to apply different restrictions to
pull requests,
otherwise I see no difference for myself.
E.g. make static analysis (do we have?), compile, styles, and javadoc
checks mandatory.
I think that relaxed requirements here will lead to bad product
Hi Igniters,
I'd like to continue discussion of IEP-54 (Schema-first approach).
Hope everyone who is interested had a chance to get familiar with the
proposal [1].
Please, do not hesitate to ask questions and share your ideas.
I've prepared a prototype of serializer [2] for the data layout descr
age-generation feature of GraalVM?
> https://www.graalvm.org/reference-manual/native-image/
>
> With the current binary marshaller, we can't even generate a native image
> for the code using our thin client APIs.
>
> -
> Denis
>
>
> On Mon, Nov 23, 2020 at 4:39 A
ber of thin clients this is important.
> > >
> > > For example, in current Ignite.NET implementation we store unsigned
> > values
> > > as signed internally,
> > > but this is a huge pain when it comes to metadata, binary objects, etc.
> > > (it is easy to
Let's add maven plugins for sanity checks at the early stage.
I've created a ticket for this [1].
Also, I've found initial pom.xml has a target version Java 8.
Do we intend to move to Java 11 (or may be next LTS) and drop Java 8 in
Ignite 3.0?
[1] https://issues.apache.org/jira/browse/IGNITE-137
nk it is much simpler:
> > - Add protocol support for those types (basically, just add more type
> ids)
> > - Treat uLong as long in Java (bitwise representation is the same)
> >
> > ANSI SQL does not have unsigned integers, so we can simply say that
> > unsigned v
will require a different comparator.
That way doesn't look simpler.
On Tue, Nov 24, 2020 at 4:23 PM Pavel Tupitsyn wrote:
> Andrey,
>
> I don't think range narrowing is a good idea.
> Do you see any problems with the simple approach I described?
>
>
> On Tue, Nov 2
posing a very simple change to the protocol - add type
> ids, but handle them the same way as signed counterparts.
>
>
> On Tue, Nov 24, 2020 at 5:00 PM Andrey Mashenkov <
> andrey.mashen...@gmail.com>
> wrote:
>
> > Pavel,
> >
> > - Treat uLong as long in J
is better, VarHandles, ForeignMemory access and so on.
>
> In both cases, I support the Java version 11 and higher for the
> development!
>
> вт, 24 нояб. 2020 г. в 15:21, Andrey Mashenkov >:
>
> > Let's add maven plugins for sanity checks at the early stage.
&g
1 - 100 of 326 matches
Mail list logo
