Denis,
I agree that p2p loading is not the best choice for CQs. Do you know if
we've already done anything in that area for the Service Grid? Are we
using/going to use Deployment SPI there as well? Either way, I think it
would make sense if services and CQs should end up using the same mechanism
+1 from me. Hadoop Accelerator build is confusing and doesn't provide any
value.
We already had a similar discussion couple of years back where I shared
some of my thoughts regarding this:
http://apache-ignite-developers.2346864.n4.nabble.com/ignite-spark-module-in-Hadoop-Accelerator-td12343.html
Guys,
>From my experience, Ignite and Spark clusters typically run in the same
environment, which makes client node a more preferable option. Mainly,
because of performance. BTW, I doubt partition-awareness on thin client
will help either, because in dataframes we only run SQL queries and I
2.7.
> So, with Spark integration via thin client we will be able to update
> Ignite cluster and Spark integration separately.
> For now, we should do it in one big step.
>
> What do you think?
>
> [1] https://apacheignite-fs.readme.io/docs/installation-deployment
>
&g
e the query may outlive
> the initiator.
>
> Val,
>
> We didn't start working on service hot redeployment yet.
> We tentatively agreed, that Deployment SPI it a good candidate as a tool
> for this task.
>
> Denis
>
> чт, 18 окт. 2018 г. в 18:44, Valentin Kulichenko &l
We should definitely allow to change type of field/column to another
compatible type. The fact that we do not allow to change Int to Long is
pretty insane. However, there are cases when it's much more complicated.
How are we going to replace Int with a String, for example? I believe this
should
Vladimir,
What is the best way to get current schema information (list of tables,
columns, etc.)?
-Val
On Mon, Nov 19, 2018 at 1:21 AM Vladimir Ozerov
wrote:
> Hi,
>
> In this case Spark integration should be fixed. as we never stated that DDL
> updates will be reflected in
Yes, will try to review this week.
-Val
On Wed, Sep 12, 2018 at 10:24 AM Dmitriy Pavlov
wrote:
> Hi Val,
>
> I'm not an expert in AWS, so could you please pick up the review?
>
> Thank you in advance!
>
> Sincerely,
> Dmitriy Pavlov
>
> вт, 11 сент. 2018 г. в 1:28, Dave Harvey :
>
> >
Hey folks,
While working with Ignite users, I keep seeing data models where a single
object (row) might contain many fields (100, 200, more...), and most of
them are strings.
Correct me if I'm wrong, but per my understanding, for every such field we
store an integer value to represent its
+1
On Wed, Jun 19, 2019 at 5:58 PM Roman Shtykh
wrote:
> +1
>
>
> On Thursday, June 20, 2019, 7:34:47 a.m. GMT+9, Andrey Gura <
> ag...@apache.org> wrote:
>
> +1
>
> On Thu, Jun 20, 2019 at 12:58 AM Denis Magda wrote:
> >
> > Igniters,
> >
> > Based on our earlier discussion [1], let's
+1
On Fri, Aug 23, 2019 at 9:40 AM Maxim Muzafarov wrote:
> +1
>
> have downloaded sources, built from the command line, run some
> examples, checked SHA checksum
>
> On Fri, 23 Aug 2019 at 19:38, Anton Kalashnikov wrote:
> >
> > +1
> > Downloaded sources, successfully assembled and started.
>
+1 Dmitry Pavlov (binding)
On Wed, Oct 30, 2019 at 12:55 PM Alex Plehanov
wrote:
> + 1 Dmitry Pavlov
>
> ср, 30 окт. 2019 г. в 20:50, Pavel Kovalenko :
>
> > +1 for Dmitry Pavlov
> >
> > ср, 30 окт. 2019 г. в 18:46, Alexei Scherbakov <
> > alexey.scherbak...@gmail.com
> > >:
> >
> > > +1 for
ased on our
> User mailing list.
>
> чт, 19 дек. 2019 г. в 11:00, Alexey Kuznetsov :
> >
> > I will vote "+1" for 3.0
> >
> > On Thu, Dec 19, 2019 at 10:57 AM Anton Vinogradov wrote:
> >
> > > My Vote was for 3.0
> > >
> > &
Is this suggested for 3.0 or 2.8?
I tend to agree with Alexey - API compatibility should be preserved within
a major version. I would oppose doing such a change in 2.x.
If this is planned for 3.0, then it's a definite +1 from me.
-Val
On Wed, Dec 18, 2019 at 11:34 PM Alexey Kuznetsov
wrote:
Fellow Igniters,
I know many of you have to stay at home these days. I have good news for
you: this doesn't mean that you can't attend Ignite meetups, as we're
switching to a virtual format. The virus is not going to stop us :)
Tomorrow I will be talking about some of the behind-the-scenes
I agree with Ivan. All contribution rules should be reasonable and should
*add value*.
For example, a requirement to include the ticket number is a great idea as
it creates a clear link between a commit and a JIRA ticket. This helps to
track the history, simplifies searches, etc.
But is it
en you want to write script
> for processing commit messages in some way you should check what
> exactly format committers use.
>
> I do not want to argue about this. But it always better to follow some
> rules then not.
>
> On Fri, Mar 20, 2020 at 3:01 AM Valentin Kulichenko
>
Ivan,
Have you considered eliminating server to client connections altogether?
Or, at the very least making the "client to server only" mode the default
one?
All the suggested names are confusing and not intuitive, and I doubt we
will be able to find a good one. A server initiating a TCP
; > sure.
> >
> > @Michael Pollind, I'll loop you in as long as you've started working on
> the
> > Ignite support for Micornaut Data
> > <https://micronaut-projects.github.io/micronaut-data/latest/guide/> and
> > came across some challenges. Just watch thi
tions (there are several "Uncomment
> this to..." lines). This complicates upgrades as well.
> >
> > Makes sense.
> > Let’s fix this.
> >
> >> The whole purpose of the IEP is to fix the above, automate and simplify
> operations for the users. The general idea i
ed
> approach.
>
> What do you think?
>
> -
> Denis
>
>
> On Fri, Aug 28, 2020 at 3:50 PM Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > Igniters,
> >
> > One of the big changes proposed for Ignite 3.0 is the so
rn so far is mostly about
> > terminology. And I suppose if it confuses me then others might be
> > confused as well. My feeling is closer to "dynamic or liquid or may be
> > evolving schema".
> >
> > [1]
> > https://people.cs.umass.edu/~yan
Hi Devin,
What are the exact configuration changes that force you to restart the
cluster? What is your process of onboarding a tenant?
The reason I'm asking is that adding new caches should not require a
cluster restart, even in the current version, but it's possible that you're
hitting one of
Hi Vladimir,
As far as I know, Redis' SortedSet is not shared. Is this correct? Is it
even possible to support similar functionality for a partitioned dataset?
-Val
On Fri, Sep 4, 2020 at 8:58 AM Denis Magda wrote:
> Hi Vladimir,
>
> Usually, LSM-storage engines serve the range searches the
;dynamic schema". I believe that we should
> > describe clearly why do we prefer one approach over others.
> >
> > 2020-09-01 3:11 GMT+03:00, Valentin Kulichenko <
> > valentin.kuliche...@gmail.com>:
> > > Hi Denis,
> > >
> > > Gene
;table" should stay and the "cache" should go considering
> that SQL is one of the primary APIs in Ignite and that DDL is supported
> out-of-the-box.
>
>
> -
> Denis
>
>
> On Mon, Sep 7, 2020 at 12:26 PM Valentin Kulichenko <
> valentin.kuliche...@gm
Igniters,
To make sure nothing slips from the scope of Ignite 3.x, I've created a
label to mark the corresponding tickets. The label is 'ignite-3'. Please
use it if you create any issue related to Ignite 3.x, or if there is an
existing issue that you think should be included there.
Here is the
Hi Yakov,
Great to have you here! :) Thanks for the inputs. My comments are below.
*Alexey*, could you please comment on the points 3 and 4?
-Val
On Sat, Oct 10, 2020 at 4:36 PM Yakov Zhdanov
wrote:
> Hi!
> I am back!
>
> Here are several ideas on top of my mind for Ignite 3.0
> 1. Client
Igniters,
As was discussed before, we've scheduled two meetups devoted to Ignite 3.0:
- Sep 15 (in English):
https://www.meetup.com/Apache-Ignite-Virtual-Meetup/events/272675408/
- Sep 17 (in Russian):
https://www.meetup.com/Moscow-Apache-Ignite-Meetup/events/272675398/
I will
e.
> > >
> > > Honestly I am not deep enough into the internals of ignite to know how
> > > this might work for the platform, was more describing what I'm seeing
> > from
> > > a bigger picture trend
> > >
> > > Regards
> > >
> > > Ada
Hi Saikat,
This sounds very interesting - I've been thinking about how Ignite compute
engine could be enhanced, and integration with Apache Beam is one of the
options I have in mind. Can you please describe how you plan to implement
this? Will it run on top of the Ignite Compute Grid? How are you
main/java/org/apache/beam/runners/jet/JetPipelineResult.java#L68-L90
>
> Regards,
> Saikat
>
>
>
>
>
>
> On Mon, Aug 17, 2020 at 2:27 PM Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > Hi Saikat,
> >
> > This sounds very interesting -
separately. Is it reasonable to expand the scope of
> > the IEP-52 and contemplate on how to install those extensions?
> >
> > -
> > Denis
> >
> >
> > On Thu, Aug 27, 2020 at 3:40 PM Valentin Kulichenko <
> > valentin.kuliche...@gmail.com> wrote:
>
Igniters,
One of the big changes proposed for Ignite 3.0 is the so-called
"schema-first approach". To add more clarity, I've started writing the IEP
for this change:
https://cwiki.apache.org/confluence/display/IGNITE/IEP-54%3A+Schema-first+Approach
Please take a look and let me know if there are
Hi Alex,
Do you know if there is any particular reason why we introduced
the ClientException in the first place? Generally, I believe that
consistency is a good thing, but there might be something that we're
missing.
-Val
On Fri, Aug 21, 2020 at 2:33 AM Alex Plehanov
wrote:
> Hello, Igniters!
t; for communication with the server). If partition awareness is enabled
> there
> > will be 2 threads per each server connection, perhaps we should think
> about
> > moving to NIO and introducing some kind of communication thread pool.
> >
> > [1]: https://github.com/a
t;
> Regards,
> Saikat
>
>
>
>
>
> On Tue, Aug 18, 2020 at 7:29 PM Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > Hi Saikat,
> >
> > Thanks for clarifying. Is there a Beam component that monitors the state,
> > or this
Hi Pavel,
Are there any benefits of IgniteFuture over CompletableFuture?
IgniteFuture was created long ago, during the time when CompletableFuture
did not exist. There is a big chance that IgniteFuture actually became
redundant at the moment we transitioned to Java8. If that's the case, I
would
Pavel Tupitsyn wrote:
> Val, no objections from my side.
> As noted above, the only benefit of IgniteFuture is consistency across
> thin/thick APIs,
> which is probably not so important.
>
> On Thu, Aug 20, 2020 at 6:28 PM Valentin Kulichenko <
> valentin.kuliche...@gmail.co
Hi Petr,
The proposal makes sense to me - thanks for starting the discussion.
Current installation and upgrade procedures involve a lot of manual steps
and quite error-prone, we need to automate and simplify them as much as
possible.
I believe we eventually should end up with a unified
Guys,
Since we started creating IEPs related specifically for 3.0, I thought it
would be easier if we separate them from others.
I went ahead and created a subfolder under "Active Proposals" [1] and moved
the newly created IEP-52 there.
[1]
Igniters,
During the meetup dedicated to Ignite 3.0 [1], one of the items I've
mentioned was JAR based code deployment, as an alternative to peer class
loading and other mechanisms for code deployment.
As promised, I've started drafting the IEP for this change [2]. Please let
me know your
My vote is for the "distributed memory-first database". It clearly states
that Ignite is a database (which is true at this point), while still
emphasizing the in-memory computing power endorsed by the platform.
The "in-memory computing platform" is an ambiguous term and doesn't really
reflect
mpute
> projection using an attribute based selection for nodes that want to be
> listeners for the events. The messaging rate is relatively low (a few
> messages a second) so this should be pretty workable.
>
> Raymond.
>
> On Thu, Sep 17, 2020 at 3:27 AM Valentin Kulichenko <
Igniters,
I would like to resurrect this discussion, as we have a chance to make the
change in Ignite 3.0.
The 'cache' term is clearly outdated and does not describe the
functionality of Ignite. It looks like the term 'table' got the most
support so far, and I think it quite accurately describes
ator that isn't being
> > > highlighted
> > > > >>> but Is unique feature to Ignited, and the primary reason we
> ended
> > up
> > > > here;
> > > > >>> The integration with spark and it's distributed/shared
> > > >
y as JAR files.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> пт, 25 сент. 2020 г. в 04:43, Valentin Kulichenko <
> valentin.kuliche...@gmail.com>:
>
> > Igniters,
> >
> > During the meetup dedicated to Ignite 3.0 [1], one of the items I've
> > mentio
Why does the control.sh use JVM_OPTS in the first place? Is there a case
when a user might need to modify them? I can't think of one.
-Val
On Thu, Sep 24, 2020 at 6:42 AM Evgenii Zhuravlev
wrote:
> Ilya,
>
> You can get absolutely the same behaviour when you set JVM_OPTS even
> without Docker.
> > define
> > > > > > > > what the environment looks like ( these could be k8s objects
> )
> > > they
> > > > > > could
> > > > > > > > be spring-configuration objects? They could be something that
> > you
&
+1 for deprecating/removing NONE mode.
Alexey, what do you think about the SYNC mode? In my experience, it does
not add much value as well. I would go as far as removing the
rebalancingMode parameter altogether (probably in 3.0).
-Val
On Mon, Jul 20, 2020 at 11:09 AM Ivan Pavlukhin wrote:
>
Igniters,
This Wednesday at 10am Pacific Time, I will be conducting a webinar devoted
to different deployment strategies that can be used with Apache Ignite. I
will talk about how Ignite can be used as a cache, as a data grid, how it
can be integrated with databases and other data sources, etc.
> > before
> > > starting the 3.0 task.
> > >
> > > I will advise against targeting large new features at 3.0. They can be
> > > added in subsequent point releases, whereas we can't really remove or
> > > remodel stuff in point releases.
> &
ort for the thick clients but that waits.
>
>
> -
> Denis
>
>
> On Tue, Aug 11, 2020 at 3:34 PM Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > Hi Saikat,
> >
> > Absolutely, we should revisit the existing APIs and decide which we wan
ntroduced
> > for this part.
> >
> > Also, it seems that full JDK11 support (including building) would be a
> > huge milestone and a sign of healthy modern project that tends to be on
> the
> > verge of mainstream technologies and not the stockpile of legacy
> lefto
e stockpile of legacy leftovers
> (fully support Iliya in removing all that was deprecated and/or marked as
> unused anymore).
>
>
> > On 8 Aug 2020, at 02:00, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
> >
> > Igniters,
> >
plan release together and learn more about Ignite in
> the process :)
>
> Regards
> Saikat
>
>
>
> On Thu, Aug 6, 2020 at 7:12 PM Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > Hi Saikat,
> >
> > That surely is a great idea. We w
are stored in specific repositories?
-Val
On Tue, Aug 11, 2020 at 11:48 PM Petr Ivanov wrote:
> Hi, Val.
>
> On 12 Aug 2020, at 01:31, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> Hi Petr,
>
> I agree -- we should better modularize the platform. The cur
s anything that should be added.
-Val
On Thu, Aug 13, 2020 at 4:55 PM Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:
> Hi Ilya,
>
> Can you please describe your vision of how it should work?
>
> Let's say, I want to set up a cluster of several standalone server no
runtime, except
> for
> experimental deployments. You need to be all set before runtime starts.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> ср, 12 авг. 2020 г. в 09:48, Petr Ivanov :
>
> > Hi, Val.
> >
> > > On 12 Aug 2020, at 01:31, Va
Igniters,
I would like to kick off a discussion regarding Ignite 3.0. Ignite 2.0
exists for more than 3 years now and we've already collected a significant
list [1] of changes that we would like to have, but cannot implement
without breaking compatibility.
I think it's time to start planning for
This might be a topic for Ignite 3.0, but I do agree that the ability to
create custom node filters is unnecessary and error-prone. Attribute-based
filtering should be more than enough.
-Val
On Tue, Jul 14, 2020 at 3:15 AM Pavel Tupitsyn wrote:
> Alex,
>
> Thank you for diving into this.
>
? :)
>
> In all seriousness, do you have plans to continue working
> on this thin client and make it production-ready?
>
> On Wed, Jul 1, 2020 at 8:01 AM Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > Igniters,
> >
> > I've been learnin
Igniters,
I've been learning the Rust language lately and though that creating a thin
client in Rust would be a great exercise.
I went ahead and create a prototype which currently supports only put and
get operations with primitives and strings:
https://github.com/vkulichenko/ignite-rust-client
ering all corner cases.
>
> Considering the improvement's criticality, I would continue moving in the
> initial direction and add that particular configuration property.
> Potentially, we can put more effort throughout an Ignite 3.0 timeframe and
> remove the property altogether. @Valen
Igniters,
I've been preparing the 3.0.0-alpha1 release and got confused about the
requirements for checksums in Maven deployments. The Apache instruction [1]
states that MD5 is deprecated and SHA1 should be avoided in favor of
SHA-256 or SHA-512. However, it looks like we are still using the
;> andrey.mashen...@gmail.com
> >>>> :
> >>>
> >>>> 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
Hi Nikita,
Welcome to the community! Any help with the documentation is extremely
valuable.
I've added you to the Contributors group in Jira - you should be able to
assign tickets to yourself now.
-Val
On Thu, Dec 3, 2020 at 7:46 AM Никита Сафонов
wrote:
> Hi everyone!
> My name is Nikita
+1
On Tue, Dec 8, 2020 at 8:31 AM Вячеслав Коптилин
wrote:
> Hello Igniters,
>
> I want to start voting on removing the public API (and eventually all
> unused parts) related to the MVCC feature.
>
> This topic has already been discussed many times (at least, [1], [2]) and
> the community has
+1
On Mon, Nov 23, 2020 at 2:44 PM Denis Magda wrote:
> Igniters,
>
> With this vote, I'd like to formally wrap up our discussion on defining
> Ignite as a "distributed database" instead of an "in-memory computing"
> platform. See the following discussion for the rationale and context:
>
>
On Wed, Nov 18, 2020 at 4:24 PM Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:
> Thanks, guys. It looks like we are much closer to the consensus now. I
> totally on board with the plan, but I would also like to address the
> short-term needs. As I've already me
tarts and
> serves REST requests successfully.
>
> On Tue, Dec 15, 2020 at 10:37 PM Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > Thanks, Sergey! Looks good to me.
> >
> > -Val
> >
> > On Tue, Dec 15, 2020 at 12:12 AM Serg
Thanks, Kirill! Hopefully, this will be merged soon.
-Val
On Wed, Dec 16, 2020 at 4:54 AM Kirill Gusakov wrote:
> Hi, Valentin.
>
> PR is ready for review, some smoke tests added.
>
> On Sat, Dec 12, 2020 at 2:40 AM Valentin Kulichenko <
> valentin.kuliche...@gmail.com>
r, 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 Mashen
Hi Sergey,
Thanks for doing this.
It looks like PR #5 is already under review, so I guess it will be merged
soon. I would really love to see that, because the configuration framework
is one of the foundational components - we need it to continue building
Ignite 3.0.
As for PR #6, it looks a
Hi Kirill,
I've played with the tool a little bit and it looks great! I definitely
like the overall approach of a single script responsible for all the
operations. This should significantly improve the usability of the product.
Looks like there is a significant amount of functionality already
Igniters,
The repository for Ignite 3.x [1] was created less than a month ago, and we
already have several merged pull requests. Many thanks to everyone involved
for the contributions!
Currently, we have the following functionality available in the main branch:
- New configuration framework
build system for
> Ignite 3? As there is a new repository we possibly can update our
> build tools as well. What do you think?
>
> 2020-12-17 22:45 GMT+03:00, Valentin Kulichenko <
> valentin.kuliche...@gmail.com>:
> > Hi Dmitriy,
> >
> > I don't think there is an
Folks,
Can someone take a look at this PR? I'm generally OK with the change, but
I'm not familiar with the mechanisms used here.
-Val
On Thu, Dec 17, 2020 at 11:16 PM Ivan Pavlukhin wrote:
> Igniters,
>
> I noticed notifications about PRs in ignite-3 repository sent to
> dev-list. I suppose
guration to enable starting multiple
> instances of ignite without specifying port manually for each instance.
>
> --
> Best Regards,
> Sergey Chugunov
>
> On Sat, Dec 12, 2020 at 3:20 AM Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > Hi Ser
leases
> should be attributed.
>
> 2020-12-21 20:42 GMT+03:00, Denis Magda :
> > Certainly, the end of Jan is more realistic and reasonable. Let's talk
> this
> > out offline and then put a session on the virtual meetup's schedule.
> >
> > -
> > Denis
> &
Ilya,
I think common sense is our only friend here :) The low number of
dependencies is indeed one of the advantages of Ignite. On the other hand,
the "zero dependency" approach we've been trying to follow for the last
several years sometimes forces us to implement, stabilize and maintain a
whole
each other. What do you think?
-Val
On Thu, Dec 17, 2020 at 11:21 AM Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:
> Thanks, Kirill! Hopefully, this will be merged soon.
>
> -Val
>
> On Wed, Dec 16, 2020 at 4:54 AM Kirill Gusakov wrote:
>
>> Hi, Vale
what's coming next?
>
> As for the release process, yes, that needs to be a formal vote as long as
> you're publishing artifacts to Maven and updating the website with
> references to the binaries and documentation pages.
>
>
> -
> Denis
>
>
> On Fri, Dec 18, 2020 at 6:13 PM Valentin
are
permitted.
I'm planning to start the vote next week, presumably on Tuesday.
-Val
On Tue, Dec 22, 2020 at 9:56 AM Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:
> Ivan,
>
> Yes, you are correct - no tables, caches, compute or any other major
> features will be av
;
> https://go.gridgain.com/rs/491-TWR-806/images/Ignite_3_Plans_and_development_process.pdf
> > > >
> > > > чт, 5 нояб. 2020 г. в 11:13, Anton Vinogradov :
> > > >
> > > > > Folks,
> > > > >
> > > > > Should we perf
Igniters,
On Tuesday next week (Nov 17), Denis Magda and I will conduct a live coding
session, where we will implement a primitive Ignite-like distributed
database from scratch. We will demonstrate major components required for
such a system, show how they interact with each other and how they
that happens within the new repo is as open to the community
as possible.
Nikolay, Maxim, are you OK with this route?
-Val
On Tue, Nov 10, 2020 at 4:55 PM Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:
> Maxim,
>
> 2.x and 3.x will have to coexist for some time - I d
Thanks, guys. It looks like we are much closer to the consensus now. I
totally on board with the plan, but I would also like to address the
short-term needs. As I've already mentioned earlier, there are several
active IEPs, but we still don't have even a preliminary technical process
for working
Moti, Raymond,
Could you please describe your use cases in more detail? What are the types
used as cache keys? What is the custom logic that you use for affinity
mapping? What was the exact reason to customize versus using built-in
collocation mechanisms?
Ultimately, I'm sure that custom
Cool, makes sense to me then. Please feel free to create a ticket and mark
it with the "ignite-3" label.
-Val
On Tue, Nov 3, 2020 at 4:03 AM Alexey Kukushkin
wrote:
> Val, absolutely - our proposal affects .NET API only.
>
> вт, 3 нояб. 2020 г. в 15:00, Valentin Kulichenko &
e for query
> colocation purposes.
>
>
>
> On Tue, Nov 3, 2020 at 9:20 PM Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > Moti, Raymond,
> >
> > Could you please describe your use cases in more detail? What are the
> types
> > u
Makes sense to me. I would love to know which components/APIs are used more
than others. Obviously, we should make sure everything is anonymous and we
don't collect any private user data, but I believe this is already
guaranteed by Google Analytics.
-Val
On Tue, Nov 3, 2020 at 3:59 AM Alexey
Hi Alexey,
The IEP-54 [1] describes the data layout proposed for Ignite 3.0, it
includes various date/time types. Can you please take a look and check if
this addresses your concerns? We can then discuss further if needed.
written as
>generic Ignite objects)
>- Convert Local .NET dates to UTC inside Ignite and to it using Java
> calendars.
>
>
> вт, 3 нояб. 2020 г. в 11:10, Valentin Kulichenko <
> valentin.kuliche...@gmail.com>:
>
> > Hi Alexey,
> >
> > The IEP-54 [1] des
Ksenia, thanks for scheduling this on such short notice!
As for the original topic, I do support Alexey's idea. We're not going to
rewrite anything from scratch, as most of the components are going to be
moved as-is or with minimal modifications. However, the changes that are
proposed imply
t all keys with the same and
> to reside in the same partition for processing colocation requirements then
> I can't use the standard Ignite mapping to do this, I need to use a custom
> mapper than uses just the & components.
>
>
> On Wed, Nov 4, 2020 at 1:33 AM Valentin
han that...
>
> We have more than one key -> partition mapping for the same key (part of a
> CQRS pattern we use).
>
> Aren't key affinity functions essentially an API in any event?
>
> Cheers,
> Raymond.
>
>
> On Wed, Nov 4, 2020 at 9:54 PM Valentin Kulichenko &
I've created a ticket for this:
https://issues.apache.org/jira/browse/IGNITE-13671
-Val
On Wed, Nov 4, 2020 at 12:53 AM Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:
> Thanks, Raymond. So the reason why you couldn't use the @AffinityKeyMapped
>
E-13924
> https://issues.apache.org/jira/browse/IGNITE-13921
> https://issues.apache.org/jira/browse/IGNITE-13922
> https://issues.apache.org/jira/browse/IGNITE-13920
>
>
> On Sun, Dec 27, 2020 at 2:18 AM Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
&
at 11:21 AM Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:
> Hi Fedor,
>
> Thanks for doing this!
>
> Regarding IGNITE-13921: in the first version, the tool created the folders
> in the current directory, which created unpredictable behavior, so we
> switched
601 - 700 of 1097 matches
Mail list logo
