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 t
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 for
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 fea
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 milesto
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
ure whether 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 sai
y understand 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 se
every 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 po
-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 optimi
direct reference 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 retur
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 Kul
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.
> Per
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 11,
+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 cand
at this module 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
> &g
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 a
nullable variables should 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 Kuliche
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 d
+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
> > > Ch
+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:
> > https://dist.apache.org/repos/dist
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 and
> > > 1. Write down the 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'
; >> we want.
> > >>
> > >>> Folks, can anyone explain the rush?
> > >>
> > >> No rush from my side.
> > >>
> > >> Just want to understand your vision of integration points between
> Ignite
> > >> and
>> compatibility*.
> >>>>> No one likes when 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
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
> n
de maintenance;
> > - As a straightforward 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;
> >
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
t be other 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 a
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
limitations
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 on
ult "no-op" implementations 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" imp
7;m
> > >>> 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 mic
ake 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
&
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
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:
https://lists.apache.org/thread.html/raf7259e6ee18ae034ee7d613ba4250f2a2da1fd974ea49841625a
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.k
entioned in the ticket that "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&#
ld 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:
> &
With that, 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:
; > wrote:
> >
> >> +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.
-
or this "request headers", 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 su
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 do
+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 are
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 devel
gt; want to interfere the progress.
> >>>>
> >>>> 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
>
of the week. 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
t;>>>>
> >>>>> 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
> >>>>
ject for the recently 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 t
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 data
not too 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
nts, 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 "ignite-3"
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
ed in libraries and compilers [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 i
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:
> -
> If Ignite 3 went this way it'd remove 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&
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
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 guarante
an 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 w
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
ces/google_checks.xml
> >
> > On Fri, Aug 20, 2021 at 12:02 PM Alexei Scherbakov
> > wrote:
> > >
> > > +1
> > >
> > > пт, 20 авг. 2021 г. в 10:54, Alexander Polovtcev <
> > alexpolovt...@gmail.com>:
> > >
> > >
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 n
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 for
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 t
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 tab
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.
; > >
> > > > > > > Ignite API will (eventually) have both sync and async variants
> of
> > > > every
> > > > > > > method, where applicable,
> > > > > > > including the method that connects the client to the cluster.
ttps://www.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
public API
> > - 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:
> >
> >
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 w
Actually “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 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 n
w.c-sharpcorner.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
> >>
> > >> 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 i
upitsyn :
> > >
> > > > 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 boxi
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:
> Igni
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 aut
VmOptions will print VM arguments 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.
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
said
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 KeyValueBinar
r a particular version, I'm not sure. Do
> > you
> > > > 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 sc
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 in-memo
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: sen
1 - 100 of 1228 matches
Mail list logo
