Congrats, folks! This is huge!
-Val
On Mon, Nov 21, 2022 at 11:16 AM Ivan Daschinsky
wrote:
> Cool, the first beta is a real achievement! Congrats!
>
> пн, 21 нояб. 2022 г. в 18:20, Igor Sapego :
>
> > Congrats, guys!
> >
> > Best Regards,
> > Igor
> >
> >
> > On Thu, Nov 17, 2022 at 4:39 PM
+1
On Thu, Jun 9, 2022 at 9:17 AM Alexander Polovtcev
wrote:
> Looks good, so many great features! +1
>
> On Thu, Jun 9, 2022 at 6:42 PM Andrey Gura wrote:
>
> > Dear Community,
> >
> > In the last few month the following major features have been added:
> >
> > - Pluggable storages: ability
Igniters,
I'm happy to announce that the 4th alpha version of Ignite 3 is out!
On top of the functionality that was previously released, Alpha 4 adds
the following major features:
- Object mappings for table views
- DDL
- Transactional API and protocol
Code examples have been added
Igniters,
Apache Ignite 3.0.0-alpha4 RC1 has been accepted.
4 "+1" votes received:
- Valentin Kulichenko (binding)
- Igor Sapego (binding)
- Denis Magda (binding)
- Andrey Gura (binding)
No "0" or "-1" votes.
Vote thread:
h
+1 (binding)
On Tue, Jan 25, 2022 at 11:43 AM Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:
> Dear Community,
>
> Ignite 3 is moving forward and I think we're in a good spot to release
> another alpha version. In the last few month the following major features
Dear Community,
Ignite 3 is moving forward and I think we're in a good spot to release
another alpha version. In the last few month the following major features
have been added:
- Transactional API
- Record and KeyValue views with POJO mapping support
- DDL
This is a significant
at 11:53 AM Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:
> -1 until we finish the discussion in another thread.
>
> The original problem we're trying to solve here is related to metrics,
> which will still be broken because of the service() method. Therefore, in
&g
r we need extra voting for deprecating
> 'service()' and, as earlier and making 'serviceProxy()' return proxy
> every time. Several active contributors have said their 'yes' for both
> in the thread.
>
> Several active contributors have already said their 'yes'.
>
> 23.01.2
tand that: we need to revert the previous patch,
> update it with the deprecation, and submit it again to master?
>
>
>
> On Sun, Jan 23, 2022 at 3:51 AM Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > If we already agreed to deprecate the service() method, then
time.
>
> 2) Deprecate `/service()/`. We've already discussed that here: [1].
> Please see my previous message in the thread.
>
>
>
> [1] https://www.mail-archive.com/dev@ignite.apache.org/msg44062.html
>
>
> On 20.01.2022 22:48, Valentin Kulichenko wrote:
> >
Hi Mark,
Thanks for letting us know. We will fix this.
-Val
On Thu, Jan 20, 2022 at 8:56 AM Mark Thomas wrote:
> Ignite developers,
>
> I noticed that your download page is incorrectly linking to
> dlcdn.apache.org for hashes and signatures. As per the release policy
> [1], these links MUST
-1 until we finish the discussion in another thread.
The original problem we're trying to solve here is related to metrics,
which will still be broken because of the service() method. Therefore, in
the way the change is proposed, it doesn't fix the issue, but removes an
existing performance
e of local/
>
> /* services which you can get by, for example, {@link
> IgniteServices#service(String)}./
>
>
> On 20.01.2022 00:20, Valentin Kulichenko wrote:
> > BTW, there is also the service() method that can only return an instance
> > and never returns a
BTW, there is also the service() method that can only return an instance
and never returns a proxy. Does it corrupt the metrics as well?
-Val
On Wed, Jan 19, 2022 at 1:09 PM Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:
> Maxim,
>
> The reason I'm asking is that
; > What are the metrics that are being affected by this?
>
> Only service metrics, that calculates duration of service execution. Check
> this ticket [1]
>
> [1] https://issues.apache.org/jira/browse/IGNITE-12464
>
>
> On Wed, Jan 19, 2022 at 1:22 AM Valentin Kulichenko &l
What are the metrics that are being affected by this?
-Val
On Tue, Jan 18, 2022 at 3:31 AM Вячеслав Коптилин
wrote:
> Hello Igniters,
>
> IMHO, this is not a good idea to change the behavior of serviceProxy()
> depending on statistics (enabled/disabled). It seems counterintuitive to
> me.
>
Igniters,
Ignite 3 is moving forward and I think we're in a good spot to release
another alpha version. In the last few month the following major features
have been added:
- Transactional API
- Record and KeyValue views with POJO mapping support
- DDL
I've created the release branch based on the
I tend to agree that providing proper exception to the client is enough in
this case, no need to stop server nodes. However, I believe that's how it
used to work before we added failure handlers. So probably there was a
reason for the current implementation? Does anyone know?
-Val
On Tue, Jan
+1 for option 2
On Thu, Jan 13, 2022 at 6:17 AM Anton Vinogradov wrote:
> +1 to option 4
>
> On Thu, Jan 13, 2022 at 5:15 PM Pavel Tupitsyn
> wrote:
>
> > +1 to option 2
> >
> > On Thu, Jan 13, 2022 at 3:52 PM Roman Puchkovskiy <
> > roman.puchkovs...@gmail.com> wrote:
> >
> > > +1 to option 2
+1
On Mon, Jan 10, 2022 at 7:37 AM Pavel Tupitsyn wrote:
> +1
>
> Checked .NET binaries, docs, examples, nuget packages.
>
> On Mon, Jan 10, 2022 at 3:53 PM Nikita Amelchev
> wrote:
>
> > Dear Community,
> >
> > The release candidate (2.12.0-rc2) is ready.
> >
> > I have uploaded a release
should be removed, I will file a specific
> ticket for it.
>
> ср, 5 янв. 2022 г., 22:26 Valentin Kulichenko <
> valentin.kuliche...@gmail.com
> >:
>
> > Hi Ivan,
> >
> > Do we have a ticket for this?
> >
> > -Val
> >
> > On
Hi Ivan,
Do we have a ticket for this?
-Val
On Fri, Dec 3, 2021 at 10:58 AM Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:
> I think we can safely remove it.
>
> -Val
>
> On Thu, Dec 2, 2021 at 11:52 PM Ivan Daschinsky
> wrote:
>
>> Hi, igniter
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 Apache Ignite project. He joined the
community in 2016.
He participated in the development of Ignite 1.x, 2.x
be avoided as much as
> possible, but not all developers share this point of view. And
> especially in Ignite codebase it was quite common to use nullable
> variables, for the first time it was very unusual for me.
>
> 2021-12-20 22:06 GMT+03:00, Valentin Kulichenko <
> valentin.ku
Neither solution is completely bulletproof, and I don't think that's what
we are looking for. We need something that provides a reasonable value, but
also does not clutter the code with too many annotations.
I would also keep in mind that annotations are used not only for static
analysis, but by
+1
On Mon, Dec 20, 2021 at 5:39 AM Alex Plehanov
wrote:
> +1
>
> Checked build from the source, cluster startup with 2 nodes.
>
> пн, 20 дек. 2021 г. в 16:27, Nikolay Izhikov :
>
> > +1 (binding)
> >
> > > 20 дек. 2021 г., в 16:20, Ivan Daschinsky
> > написал(а):
> > >
> > > +1 from me
> > >
+1
On Fri, Dec 17, 2021 at 6:01 AM Denis Magda wrote:
> +1 (binding)
>
> -
> Denis
>
>
> On Fri, Dec 17, 2021 at 7:20 AM Maxim Muzafarov wrote:
>
> > The release candidate for the 2.11.1 version is ready.
> >
> >
> > I have uploaded a release candidate to:
> >
Same here. The second option seems the most reasonable.
-Val
On Thu, Dec 16, 2021 at 8:07 AM Alexei Scherbakov <
alexey.scherbak...@gmail.com> wrote:
> +1 for 2
>
> чт, 16 дек. 2021 г. в 18:50, Pavel Tupitsyn :
>
> > Option 2 seems the most sensible.
> > It translates to/from other languages
he differences between the system cache and the
> > metastorage, and provide a transition guide for plugin developers.
> > >
> > > Don’t think we need any transition guide.
> > >
> > > > I don't think it's reasonable to do this earlier than mid
t; >>
> > >>> Folks, can anyone explain the rush?
> > >>
> > >> No rush from my side.
> > >>
> > >> Just want to understand your vision of integration points between
> Ignite
> > >> and plugins.
> > >>
&g
en their app breaks suddenly because of a library
> >> update.
> >>>>>
> >>>>> We know about one use case for sys-cache in GridGain, but there may
> be
> >>>>> more, no one knows.
> >>>>> Every breaking change should be c
I think we can safely remove it.
-Val
On Thu, Dec 2, 2021 at 11:52 PM Ivan Daschinsky wrote:
> Hi, igniters.
>
> Recently I've discovered one fact
> 1. GridShmemCommunicationClient and all shmem functionality are broken
> since 2.10. In master it is broken since August 2020. And nobody have
>
ard solution plugins can create their own internal
> > caches and use them ever they like (or use the metastorage as I
> > mentioned earlier). Moving system cache to plugin doesn't look so
> > complicated and harmful;
> >
> > On Mon, 29 Nov 2021 at 23:07, Valentin
Maxim,
You're right that the system cache is still likely to be used by plugins.
We at GridGain use it for security features, for example. As far as I know,
that's not the only case.
I also agree that the metastorage should be the preferred way for this kind
of purposes, but is there any harm in
cases as
well. What do you think?
-Val
On Mon, Nov 29, 2021 at 10:59 AM Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:
> I like Alexei's suggestion. This seems to be the most transparent and
> explicit approach. Basically, this ensures that the user is always aware
I like Alexei's suggestion. This seems to be the most transparent and
explicit approach. Basically, this ensures that the user is always aware of
whether an operation is enlisted in a transaction or not. Any other option
is either error-prone, or introduces unnecessary counter-intuitive
Igniters,
I'm happy to announce that the third alpha version of Ignite 3 is out!
On top of the functionality that was previously released, Alpha 3 adds
the following major features:
- New SQL engine based on Apache Calcite with implemented JDBC driver.
- Persistence implementation based
ns for them.
> > > Unfortunately, we are currently unable to do the same in .Net because
> > > such a feature is not supported in C# 4.0 (it's available in C# 8.0).
> > >
> > > Can we add default "no-op" implementations for init/execute/cancel
>
; only
> > >>>>> worried about exposing this to the end user.
> > >>>
> > >>> I'm talking about not Ignite auth, but external auth. Here I am
> > >> considering
> > >>> Ignite Service Grid as a microservice platform.
> &
sure that users will not use a wrong JIRA project often?
>
> 2021-10-05 2:50 GMT+03:00, Valentin Kulichenko <
> valentin.kuliche...@gmail.com>:
> > Ivan,
> >
> > I'm not pushing, I'm trying to apply the lazy consensus. It soon will be
> a
> > whole
Cancelling the vote due to controversial opinions. We will look for
alternative solutions.
-Val
gt; from scratch (from the code point of view).
> > > >
> > > > ср, 6 окт. 2021 г. в 00:23, Maxim Muzafarov :
> > > >
> > > > > - 0 from me.
> > > > >
> > > > > This is OK if the projects are different,
Igniters,
Apache Ignite 3.0.0-alpha3 RC1 has been accepted.
3 "+1" votes received:
- Denis Magda (binding)
- Saikat Maitra (binding)
- Pavel Tupitsyn (binding)
No "0" or "-1" votes.
Vote thread:
The vote is successful with three binding +1 votes.
-Val
On Fri, Oct 15, 2021 at 12:21 AM Pavel Tupitsyn
wrote:
> Val,
>
> Good point, let's upload nupkg files to SVN for both 2.x and 3.x RCs.
>
> On Thu, Oct 14, 2021 at 11:49 PM Valentin Kulichenko <
> valentin.kulich
at "Note that NuGet, unfortunately,
> > has
> > > >> no
> > > >> concept of "staging" (unlike Maven). A package with the given
> version
> > > can
> > > >> be published only once, and it can't be undone. We can only p
know what we are going to upload and can check that everything is
> > right.
> >
> > WDYT?
> >
> > Best Regards,
> > Igor
> >
> >
> > On Wed, Oct 13, 2021 at 8:03 PM Valentin Kulichenko <
> > valentin.kuliche...@gmail.com> wrote:
> >
&
at, will you be okay if we proceed with the release, and upload the
NuGet package after the vote is accepted?
We can then have a separate discussion on the overall packaging approach.
-Val
On Wed, Oct 13, 2021 at 9:57 AM Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:
>
gt;
> >> +1 (binding)
> >>
> >> Regards
> >> Saikat
> >>
> >> On Tue, Oct 12, 2021 at 5:03 PM Denis Magda wrote:
> >>
> >> > +1 (binding)
> >> >
> >> > -
> >> > Denis
> >> >
&
Dear Community,
Ignite 3 development is moving forward. In the last several months we've
added the following features:
- New SQL engine based on Apache Calcite + JDBC driver.
- Persistence implementation based on RocksDB.
- New binary client protocol with an implementation in Java.
-
ders", it can
> > drastically improves this aspects of our service grid framework.
> >
> >
> > пн, 11 окт. 2021 г. в 00:48, Valentin Kulichenko <
> > valentin.kuliche...@gmail.com>:
> >
> >> I agree with Pavel. The suggested approach is i
I agree with Pavel. The suggested approach is indeed utilized quite
frequently, but it's inherently error-prone.
The main issue is that it creates implicit assumptions about the behavior
of both the service and the user's code. For example, if the user's code
must provide a username, what if it
+1
On Mon, Oct 4, 2021 at 4:52 PM Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:
> Hello Community,
>
> As discussed in [1], I would like to propose the creation of a separate
> Jira project and Confluence space for Ignite 3.
>
> Ignite 2 and Ignite 3 a
Hello Community,
As discussed in [1], I would like to propose the creation of a separate
Jira project and Confluence space for Ignite 3.
Ignite 2 and Ignite 3 are developed in parallel in separate repos, so we
need a clear separation in other tools as well - this will help to
streamline the
t; >>>>
> >>>> Respect to the developers who have courage to develop such complex
> >>>> things from scratch.
> >>>>
> >>>>> 29 сент. 2021 г., в 12:55, Petr Ivanov
> >>>>> нап
Hi Denis,
Did you make any progress on this topic?
-Val
On Wed, Apr 21, 2021 at 6:11 AM Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:
> Danis,
>
> Got it, thanks. Please provide the link to the IEP when you have one, I’d
> be happy to review!
>
> -Val
. If there is no clear picture
on option #2 by then, I suggest we go with #1.
-Val
On Tue, Sep 28, 2021 at 11:22 PM Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:
> Folks,
>
> Versioning is a separate topic. We agreed on the current scheme in March
> [1]. If someone thinks
;>>>
> >>>>> I like the major version update like Ignite 3.0 but if we were to
> come
> >>>>> up
> >>>>> with a name my other suggestion would be
> >>>>>
> >>>>> Ignite-kernel
> >>>>>
y released
> versions 3. A different GitHub project is not that disturbing.
>
> -
> Denis
>
>
> On Fri, Sep 24, 2021 at 4:09 AM Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > Denis,
> >
> > From a purely technical perspective
Hello Abhinav,
Spark 3 support definitely becomes higher priority for Ignite as more
people transition to it from Spark 2. I'm sure someone in the community
will pick this up soon.
In the meantime, could you please give a little more detail on how you use
Ignite with Spark? Are you using the
oo urgent.
>
> Sincerely,
> Dmitriy Pavlov
>
> On 2021/09/21 10:37:42, Valentin Kulichenko
> wrote:
> > Hi Dmitry,
> >
> > According to Infra, this has to be done through
> http://selfserve.apache.org/,
> > but only PMC chairs have access.
> >
>
Hi Dmitry,
According to Infra, this has to be done through http://selfserve.apache.org/,
but only PMC chairs have access.
Could you please assist with the creation of the Jira project and
Confluence space?
-Val
On Tue, Sep 21, 2021 at 10:46 AM Valentin Kulichenko <
valentin.kuli
and it is not clear where to put them at the moment.
> >
> > On Sat, Sep 18, 2021 at 4:22 AM Valentin Kulichenko <
> > valentin.kuliche...@gmail.com> wrote:
> >
> >> Igniters,
> >>
> >> I think it's clear to all of us that Ignite 2.
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 same Jira project, which seems to
complicate the ticket management.
For example, we use the
How do we handle the "equality" part in 2.x? The same problem exists there
as well, but we still somehow return a Map.
Generally, I like Pavel's ideas, but there are a couple of issues with
them. Firstly, Java developers are really used to maps in this context.
Introducing something else might be
lers [1].
>
> [1] https://github.com/dotnet/roslyn/blob/main/CONTRIBUTING.md
>
> On Wed, Sep 8, 2021 at 9:49 PM Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > I don't think we should ban anything. Streams API is just a tool in the
> >
I don't think we should ban anything. Streams API is just a tool in the
toolbox - it should be used appropriately. It's up to the contributor and
reviewer(s) to identify whether a particular usage might cause performance
issues.
-Val
On Wed, Sep 8, 2021 at 8:01 AM Alexander Polovtcev
wrote:
>
ve a lot of boiler plate/wrapper that
> we
> > wrote to get what you're suggesting here.
> >
> > Regards,
> > Courtney Robinson
> > Founder and CEO, Hypi
> > Tel: ++44 208 123 2413 (GMT+0) <https://hypi.io>
> >
> > <https://hypi.io>
&g
Hi Pavel,
I've created a thread.
-Val
On Mon, Sep 6, 2021 at 12:02 PM Pavel Tupitsyn wrote:
> Val,
>
> Would you like me to start the discussion about sync-over-async in Ignite 3
> Java APIs, or do you plan to do it yourself?
>
> On Fri, Sep 3, 2021 at 10:10 PM V
Igniters,
I would like to gather some opinions on whether we want to focus on sync vs
async APIs in Ignite 3.
Here are some initial considerations that I have:
1. Ignite 2.x is essentially "sync first". Async APIs exist, but they use
non-standard IgniteFuture and provide counterintuitive
n affect performance
>
>
> However, I'm not so sure about Java, where async/await are not present,
> overall async usage seems to be rarer, and removing sync methods may become
> an obstacle for the users in some cases.
> Let's create a separate discussion and see what others thin
Hi Pavel,
I've looked at the IEP and the public API - looks good to me.
Quick question - do you plan to add sync methods to the interfaces, or
you're thinking to only leave async? If the latter, what are the arguments
for this? The reason I'm asking is that I'm actually thinking about
suggesting
_checks.xml
> >
> > On Fri, Aug 20, 2021 at 12:02 PM Alexei Scherbakov
> > wrote:
> > >
> > > +1
> > >
> > > пт, 20 авг. 2021 г. в 10:54, Alexander Polovtcev <
> > alexpolovt...@gmail.com>:
> > >
> > > > Hi,
Pavel,
The configuration framework is designed to support dynamic configuration
changes - I doubt this is needed for the client side. I think we should
start with simple POJOs or builders.
-Val
On Sat, Aug 21, 2021 at 7:03 AM Ivan Daschinsky wrote:
> As for me, it is very strange purpose and
Igniters,
I would like to discuss a potential change to the coding guidelines for
Ignite 3. Currently, we're using the existing guidelines inherited from
Ignite 2, which are described here:
https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines
Current guidelines, however, exist
Hi Courtney,
Generally speaking, query caching certainly makes sense. As far as I know,
Ignite 2.x actually does that, but most likely there might be room for
improvement as well. We will look into this.
As for the SQL API - the answer is yes. The requirement for a dummy cache
is an artifact of
Atri,
Sure, go ahead. Let's put the ideas on paper and have a discussion.
-Val
On Fri, Jul 23, 2021 at 10:59 AM Atri Sharma wrote:
> Thanks Andrey.
>
> I have collected answers or proposals to many of these questions and
> would like to start a wiki page covering what we can do for Ignite 3.
:
> The standard ways to deal with text based searches in SQL are the
> CONTAINS operator, the LIKE operator or specific functions
> (REGEXP_MATCHES, for eg). I do not think any of these are supported by
> Calcite at the moment.
>
> On Fri, Jul 23, 2021 at 11:20 PM Valentin Kulichenko
>
In my experience, one of the biggest usability issues with the current
support of text queries is that they are completely decoupled from SQL.
I.e. you can either execute a SQL query OR a text query. Modern databases,
on the other hand, typically allow creating text-based indexes within
regular
Pavel Tupitsyn wrote:
> Val,
>
> My suggestion is to have Ignition class in ignite-client module.
>
> On Fri, Jul 9, 2021 at 11:01 PM Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > Pavel,
> >
> > Ivan actually brings a good point.
ally) have both sync and async variants
> of
> > > > every
> > > > > > > method, where applicable,
> > > > > > > including the method that connects the client to the cluster.
> > > > > > >
> > > > > > >
.baeldung.com/java-redis-lettuce
>
> чт, 8 июл. 2021 г., 23:47 Valentin Kulichenko <
> valentin.kuliche...@gmail.com
> >:
>
> > Ivan,
> >
> > Can you please clarify what you mean by "separate creation of client and
> > connection"? Can you give a
I
> > - Make Ignition a class, not an interface
> > - Add static Ignition#startClient
> >
> > Sounds good?
> >
> > On Thu, Jul 8, 2021 at 6:13 AM Valentin Kulichenko <
> > valentin.kuliche...@gmail.com> wrote:
> >
> > > Hi Iv
t; On Thu, Jul 8, 2021 at 6:13 AM Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > Hi Ivan,
> >
> > Ignition IS the entry point to Ignite, so I'm not sure I got your point
> :)
> > Where is the contradiction?
> >
> > Either way, p
lly “Ignition” naming always confused me. I think about
> it as some fancy named API entry point for Ignite. Perhaps it is a good
> moment to revisit naming.
>
> > On 8 Jul 2021, at 07:09, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
> >
> > Hi Pa
Hi Pavel,
I don't think we will need the pure embedded mode, but we still need to be
able to access the API from compute and services. That said, there are two
usages of the 'Ignite' API:
1. Remote, via the binary protocol.
2. Local - needed for compute and services. (This is how it works
orner.com/article/out-parameter-in-c-sharp-7/
>
>
> вт, 6 июл. 2021 г., 22:30 Valentin Kulichenko <
> valentin.kuliche...@gmail.com
> >:
>
> > Pavel,
> >
> > Optionals are available in Java and we can use them. This is still boxing
> > though, and I don't k
>>
> > >> As for me, I want to take part in implementing python and golang thin
> > >> clients for ignite 3, so consider my remarks using this info. I am not
> > >> just
> > >> a rude critic,
> > >> I am just interested in con
> >
> > > > Val,
> > > >
> > > > > I don't think there is a significantly better way
> > > > > of doing this in Java.
> > > >
> > > > Yep looks like there is no way to return two values without boxing.
> > > &
Pavel,
That's a good point, but I don't think there is a significantly better way
of doing this in Java.
There should be a way to check if a field is nullable or not though. Schema
already provides this information, doesn't it?
-Val
On Mon, Jul 5, 2021 at 11:03 AM Pavel Tupitsyn wrote:
>
Daschinsky wrote:
> Val, am I right, that kv view over the tuples is just simple mapping from
> POJO to tuple? No collections, no nested objects? I have discussed this in
> private with Igor and Pavel and they told me different info.
>
> чт, 1 июл. 2021 г., 19:43 Vale
21 г., 19:51 Valentin Kulichenko <
> valentin.kuliche...@gmail.com
> >:
>
> > Ivan,
> >
> > IP addresses (e.g. IGNITE_TCP_DISCOVERY_ADDRESSES) and file paths
> > (e.g. IGNITE_CONFIG_URL) are often considered sensitive information. Data
> > related to
uments even if
> sensitive data is restricted?
>
> What do you think about an extra JVM option?
>
> чт, 1 июл. 2021 г. в 19:51, Valentin Kulichenko <
> valentin.kuliche...@gmail.com>:
>
> > Ivan,
> >
> > IP addresses (e.g. IGNITE_TCP_DISCOVERY_ADDRESSES
efault and block it wheb set to true
>
> чт, 1 июл. 2021 г., 19:45 Atri Sharma :
>
> > What if we allowed a blocklist of parameters that are never printed?
> >
> > On Thu, 1 Jul 2021, 22:06 Valentin Kulichenko, <
> > valentin.kuliche...@gmail.com> wrote:
>
Ivan,
I was answering your question about the KV API. The API I provided has been
discussed and agreed upon. One of the goals of the protocol is to implement
this API, so it should give you a clear idea of what we're looking for.
Of course, I agree with you that the protocol should be simple and
ity through obscurity, an obvious and a well-known anti
> pattern. I suppose that printing jvm options, that is registered by
> @IgniteSystemProperty annotation is an ideal variant
>
> чт, 1 июл. 2021 г., 19:25 Valentin Kulichenko <
> valentin.kuliche...@gmail.com
> >:
>
Folks,
*Anything* that a user provides to the system can potentially be considered
sensitive information. This includes the VM arguments. We can't predict
what exactly one can put there, so let's not make assumptions.
When dealing with security, we should be as conservative as possible. That
Ivan,
Regarding the API, please take a look at this package:
https://github.com/apache/ignite-3/tree/main/modules/api/src/main/java/org/apache/ignite/table
'Table' is the primary API, which works with raw tuples. There are also
multiple views on top of it, including KeyValueView and
> have a use case in mind for this? If not, I would keep this internal
> > >
> > > Ok, we can keep the Table.schema(ver) method internal, as long as
> > > Table.schemas() is public and includes schema versions.
> > >
> > >
> > > > We already
Igniters,
I'm happy to announce that Ignite 3 project reached a significant
milestone, as we release the 2nd alpha version of the product.
On top of the functionality that was previously released, Alpha 2 adds
the following major features:
- Replication infrastructure based on Raft.
- New
Hi Pavel,
Please see my comments below.
-Val
On Tue, Jun 29, 2021 at 2:23 PM Pavel Tupitsyn wrote:
> Igniters,
>
> While working on "IEP-76 Thin Client Protocol for Ignite 3.0" [1] (to be
> discussed separately), the following suggestions for the Table API came up:
>
> 1. Expose table IDs:
1 - 100 of 1097 matches
Mail list logo
