Cpp thin client transactions support ready for review.

[Zhenya Stanilovsky]

Thanks for all who participated in review.
Cpp transactions functionality already in master.
Appropriate wiki page [1] was updated.
 
[1] https://cwiki.apache.org/confluence/display/IGNITE/Thin+clients+features
 
>
>
>Great, I'll take a look.
>
>Best Regards,
>Igor
>
>
>On Mon, Aug 24, 2020 at 8:33 AM Zhenya Stanilovsky
>< arzamas...@mail.ru.invalid > wrote:
>
>>
>>
>> Thanks Ivan Daschinsky for review, does anyone more who could check it ?
>>
>> thanks !
>> >Igniters, seems i complete with transactions in thin cpp client
>> >implementation [1], part of iep-34 [2].
>> >Can anyone review my decision ?
>> >Failed test seems not mine, looks like after fresh master rebase it will
>> >gone.
>> >
>> >[1]  https://issues.apache.org/jira/browse/IGNITE-13308
>> >[2]
>> >
>>  
>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
>> >
>> >
>> >
>>
>>
>> 
 
 
 
 

Re: Apache Ignite 2.9.0 RELEASE [Time, Scope, Manager]

[Nikolay Izhikov]

Hello, Igniters.

Alexey, please, include one more Python thin client fix [1] into the 2.9 release
It fixes kinda major issue - "Python client returns fields in wrong order since 
the 2 row when fields_count>10"

[1] https://issues.apache.org/jira/browse/IGNITE-12809
[2] 
https://github.com/apache/ignite/commit/38025ee4167f05eaa2d6a2c5c2ab70c83a462cfc

> 31 авг. 2020 г., в 19:23, Alexey Goncharuk  
> написал(а):
> 
> Alexey, thanks, got it. I am not sure we can optimize anything out of the
> message factory with suppliers (at least I have no ideas right now), so
> most likely the only move here is to switch back to the switch approach
> somehow preserving the metrics part. Probably, inlining the Ignite messages
> to the IgniteMessageFactoryImpl should do the trick. Let me explore the
> code a bit.
> 
> P.S. I am surprised by the impact this part makes for the performance.
> Message creation is indeed on the hot path, but a single virtual call
> should not make that much of a difference given the amount of other work
> happening during the message processing.
> 
> пн, 31 авг. 2020 г. в 18:33, Alex Plehanov :
> 
>> Alexey, sorry, I wrongly interpreted our benchmark results. Actually, we
>> were looking for a drop using bi-sect in the range between e6a7f93 (first
>> commit in the 2.9 branch after 2.8 branch cut) and 6592dfa5 (last commit in
>> the 2.9 branch). And we found these two problematic commits.
>> 
>> Perhaps only IGNITE-13060 (Tracing) is responsible for a drop between
>> 2.8.1 and 2.9 (we have benchmarked 2.8.1 vs 2.9 with reverted IGNITE-13060
>> now and performance looks the same)
>> 
>> Ticket IGNITE-12568 (MessageFactory refactoring) is not related to drop
>> between 2.8.1 and 2.9, but still has some performance problem, and we can
>> win back IGNITE-13060 drop by this ticket.
>> 
>> Do we need more investigation on IGNITE-13060 or we leave it as is?
>> 
>> What should we do with IGNITE-12568 (MessageFactory refactoring)?
>> 
>> пн, 31 авг. 2020 г. в 13:25, Alexey Goncharuk >> :
>> 
>>> Alexey,
>>> 
>>> While investigating, I found that IGNITE-12568 has an incorrect fix
>>> version and is actually present in ignite-2.8.1 branch [1], so it cannot be
>>> the source of the drop against 2.8.1.
>>> 
>>> P.S. Looks like we need to enforce a more accurate work with fix versions
>>> or develop some sort of tooling to verify the fix versions.
>>> 
>>> --AG
>>> 
>>> [1]
>>> https://github.com/apache/ignite/commit/3e492bd23851856bbd0385c6a419892d0bba2a34
>>> 
>>> пн, 31 авг. 2020 г. в 12:42, Alexey Goncharuk >>> :
>>> 
 пт, 28 авг. 2020 г. в 11:16, Alex Plehanov :
 
> Guys,
> 
> We have benchmarked 2.9 without IGNITE-13060 and IGNITE-12568 (reverted
> it
> locally) and got the same performance as on 2.8.1
> 
> IGNITE-13060 (Tracing) - some code was added to hot paths, to trace
> these
> hot paths, it's clear why we have performance drop here.
> 
> IGNITE-12568 (MessageFactory refactoring) - switch/case block was
> refactored to an array of message suppliers. The message factory is on
> the
> hot path, which explains why this commit has an impact on total
> performance.
> I've checked JIT assembly output, done some JMH microbenchmarks, and
> found
> that old implementation of MessageFactory.create() about 30-35% faster
> than
> the new one. The reason - approach with switch/case can effectively
> inline
> message creation code, but with an array of suppliers relatively heavy
> "invokeinterface" cannot be skipped. I've tried to rewrite the code
> using
> an abstract class for suppliers instead of an interface (to
> replace "invokeinterface" with the "invokevirtual"), but it gives back
> only
> 10% of method performance and in this case, code looks ugly (lambdas
> can't
> be used). Currently, I can't find any more ways to optimize the current
> approach (except return to the switch/case block). Andrey Gura, as the
> author of IGNITE-12568, maybe you have some ideas about optimization?
> 
> Perhaps we should revert IGNITE-12568, but there are some metrics
> already
> created, which can't be rewritten using old message factory
> implementation
> (IGNITE-12756). Guys, WDYT?
> 
 
 Alexey,
 
 I see that IGNITE-12756 (metrics improvements) is already released in
 Ignite 2.8.1 while IGNITE-12568 (message factory) is only present in Ignite
 2.9. Let's revert both IGNITE-12568 and whichever new metrics created for
 2.9 that depend on the new message factory to unblock the release and deal
 with the optimizations in 2.10?
 
>>> 

Re: [DISCUSSION] Maintenance Mode feature

[Ivan Pavlukhin]

Sergey,

Actually, I missed the point that the discussed mode affects a single
node but not a whole cluster. Perhaps I mixed terms "mode" and
"state".

My next thoughts about maintenance routines are about special
utilities. As far as I remember MySQL provides a bunch of scripts for
various maintenance purposes. What user interface for maintenance
tasks execution is assumed? And what do we mean by "starting" a node
in a maintenance mode? Can we do some routines without "starting"
(e.g. try to recover PDS or cleanup)?

2020-08-31 23:41 GMT+03:00, Vladislav Pyatkov :
> Hi Sergey.
>
> As I understand any switching from/to MM possible only through manual
> restart a node.
> But in your example that look like a technical actions, that only possible
> in the case.
> Do you plan to provide a possibility for client where he can make a
> decision without a manual intervention?
>
> For example: Start node and manually agree with an option and after
> automatically resolve conflict and back to topology as a stable node.
>
> On Mon, Aug 31, 2020 at 5:41 PM Sergey Chugunov 
> wrote:
>
>> Hello Ivan,
>>
>> Thank you for raising the good question, I didn't think of Maintenance
>> Mode
>> from that perspective.
>>
>> In short, Maintenance Mode isn't related to Cluster States concept.
>> According to javadoc documentation of ClusterState enum [1] it is solely
>> about cache operations and to some extent doesn't affect other components
>> of Ignite node.
>> From APIs perspective putting the methods to manage Cluster State to
>> IgniteCluster interface doesn't look ideal to me but it is as it is.
>>
>> On the other hand Maintenance Mode as I see it will be managed through
>> different APIs than a ClusterState and this difference definitely will be
>> reflected in the documentation of the feature.
>>
>> Ignite node is a complex piece of many components interacting with each
>> other, they may have different lifecycles and states; states of different
>> components cannot be reduced to the lowest common denominator.
>>
>> However if you have an idea of how to call the feature better to let the
>> user easier distinguish it from other similar features please share it
>> with
>> us. Personally I'm very welcome to any suggestions that make design more
>> intuitive and easy-to-use.
>>
>> Thanks!
>>
>> [1]
>>
>> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/cluster/ClusterState.java
>>
>> On Mon, Aug 31, 2020 at 12:32 PM Ivan Pavlukhin 
>> wrote:
>>
>> > Hi Sergey,
>> >
>> > Thank you for bringing attention to that important subject!
>> >
>> > My note here is about one more cluster mode. As far as I know
>> > currently we already have 3 modes (inactive, read-only, read-write)
>> > and the subject is about one more. From the first glance it could be
>> > hard for a user to understand and use all modes properly. Do we really
>> > need all spectrum? Could we simplify things somehow?
>> >
>> > 2020-08-27 15:59 GMT+03:00, Sergey Chugunov
>> > :
>> > > Hello Nikolay,
>> > >
>> > > Created one, available by link [1]
>> > >
>> > > Initially there was an intention to develop it under IEP-47 [2] and
>> there
>> > > is even a separate section for Maintenance Mode there.
>> > > But it looks like this feature is useful in more cases and deserves
>> > > its
>> > own
>> > > IEP.
>> > >
>> > > [1]
>> > >
>> >
>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-53%3A+Maintenance+Mode
>> > > [2]
>> > >
>> >
>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-47:+Native+persistence+defragmentation
>> > >
>> > > On Thu, Aug 27, 2020 at 11:01 AM Nikolay Izhikov
>> > > 
>> > > wrote:
>> > >
>> > >> Hello, Sergey!
>> > >>
>> > >> Thanks for the proposal.
>> > >> Let’s have IEP for this feature.
>> > >>
>> > >> > 27 авг. 2020 г., в 10:25, Sergey Chugunov <
>> sergey.chugu...@gmail.com>
>> > >> написал(а):
>> > >> >
>> > >> > Hello Igniters,
>> > >> >
>> > >> > I want to start a discussion about new supporting feature that
>> > >> > could
>> > be
>> > >> > very useful in many scenarios where persistent storage is
>> > >> > involved:
>> > >> > Maintenance Mode.
>> > >> >
>> > >> > *Summary*
>> > >> > Maintenance Mode (MM for short) is a special state of Ignite node
>> when
>> > >> node
>> > >> > doesn't serve user requests nor joins the cluster but waits for
>> > >> > user
>> > >> > commands or performs automatic actions for maintenance purposes.
>> > >> >
>> > >> > *Motivation*
>> > >> > There are situations when node cannot participate in regular
>> > operations
>> > >> but
>> > >> > at the same time should not be shut down.
>> > >> >
>> > >> > One example is a ticket [1] where I developed the first draft of
>> > >> > Maintenance Mode.
>> > >> > Here we get into a situation when node has potentially corrupted
>> > >> > PDS
>> > >> > thus
>> > >> > cannot proceed with restore routine and join the cluster as usual.
>> > >> > At the same time node should not fail nor be stopped for manual
>> > >> > clean

Re: IEP-54: Schema-first approach for 3.0

[Ivan Pavlukhin]

Hi Val,

Thank you for raising a discussion about this significant proposal!
The subject looks very significant and can greatly affect product
spirit and user experience.

While I generally think that schema-first is a good idea, I would love
to see a thorough approaches comparison section. As we know different
databases treat data schema differently. And each way has benefits and
drawbacks. Additionally to schemeless and schema-first approaches I
remember talks about "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 :
> Hi Denis,
>
> Generally speaking, I believe that the schema-first approach natively
> addresses the issue if duplicate fields in key and value objects, because
> schema will be created for a cache, not for an object, as it happens now.
> Basically, the schema will define whether there is a primary key or not,
> and which fields are included in case there is one. Any API that we would
> have must be compliant with this, so it becomes fairly easy to work with
> data as with a set of records, rather than key-value pairs.
>
> However, could you please elaborate on the relation between Ignite and ORM?
> Is there a use case for Hibernate running on top of Ignite (I haven't seen
> one so far)? If so, what is missing exactly on the Ignite side to support
> this? In my understanding, all you need is SQL API which we already have.
> Am I missing something?
>
> -Val
>
> On Mon, Aug 31, 2020 at 2:08 PM Denis Magda  wrote:
>
>> Val,
>>
>> I would propose adding another point to the motivations list which is
>> related to the ORM frameworks such as Spring Data, Hibernate, Micronaut
>> and
>> many others.
>>
>> Presently, the storage engine requires to distinguish key objects from
>> the
>> value ones that complicate the usage of Ignite with those ORM frameworks
>> (especially if a key object comprises several fields). More on this can
>> be
>> found here:
>>
>> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Key-and-Value-fields-with-same-name-and-SQL-DML-td47557.html
>>
>> It will be nice if the new schema-first approach allows us to work with a
>> single entity object when it comes to the ORMs. With no need to split the
>> entity into a key and value. Just want to be sure that the Ignite 3.0 has
>> all the essential public APIs that would support the single-entity based
>> 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-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 any immediate thoughts,
>> > suggestions, or objections.
>> >
>> > -Val
>> >
>>
>


-- 

Best regards,
Ivan Pavlukhin

Re: IEP-54: Schema-first approach for 3.0

[Alexey Goncharuk]

Ivan,

Thank you for reminding me about the dynamic schema. I've updated the IEP
draft with more details on the approach, hopefully now it's more clear. I
think we will be able to take the best from both fixed-schema and
schemaless approaches.

вт, 1 сент. 2020 г. в 14:31, Ivan Pavlukhin :

> Hi Val,
>
> Thank you for raising a discussion about this significant proposal!
> The subject looks very significant and can greatly affect product
> spirit and user experience.
>
> While I generally think that schema-first is a good idea, I would love
> to see a thorough approaches comparison section. As we know different
> databases treat data schema differently. And each way has benefits and
> drawbacks. Additionally to schemeless and schema-first approaches I
> remember talks about "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,
> >
> > Generally speaking, I believe that the schema-first approach natively
> > addresses the issue if duplicate fields in key and value objects, because
> > schema will be created for a cache, not for an object, as it happens now.
> > Basically, the schema will define whether there is a primary key or not,
> > and which fields are included in case there is one. Any API that we would
> > have must be compliant with this, so it becomes fairly easy to work with
> > data as with a set of records, rather than key-value pairs.
> >
> > However, could you please elaborate on the relation between Ignite and
> ORM?
> > Is there a use case for Hibernate running on top of Ignite (I haven't
> seen
> > one so far)? If so, what is missing exactly on the Ignite side to support
> > this? In my understanding, all you need is SQL API which we already have.
> > Am I missing something?
> >
> > -Val
> >
> > On Mon, Aug 31, 2020 at 2:08 PM Denis Magda  wrote:
> >
> >> Val,
> >>
> >> I would propose adding another point to the motivations list which is
> >> related to the ORM frameworks such as Spring Data, Hibernate, Micronaut
> >> and
> >> many others.
> >>
> >> Presently, the storage engine requires to distinguish key objects from
> >> the
> >> value ones that complicate the usage of Ignite with those ORM frameworks
> >> (especially if a key object comprises several fields). More on this can
> >> be
> >> found here:
> >>
> >>
> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Key-and-Value-fields-with-same-name-and-SQL-DML-td47557.html
> >>
> >> It will be nice if the new schema-first approach allows us to work with
> a
> >> single entity object when it comes to the ORMs. With no need to split
> the
> >> entity into a key and value. Just want to be sure that the Ignite 3.0
> has
> >> all the essential public APIs that would support the single-entity based
> >> 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-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 any immediate
> thoughts,
> >> > suggestions, or objections.
> >> >
> >> > -Val
> >> >
> >>
> >
>
>
> --
>
> Best regards,
> Ivan Pavlukhin
>

Re: IEP-54: Schema-first approach for 3.0

[Valentin Kulichenko]

Alexey,

Thanks for adding more details to the IEP. I have a question regarding the
following:

*When an object is inserted into a table, we attempt to 'fit' object fields
to the schema columns. If a Java object has some extra fields which are not
present in the current schema, the schema is automatically updated to store
additional extra fields that are present in the object.*

Do you see this happening automatically? If so, it probably should be
optional, and even disabled by default. What do you think?

-Val

On Tue, Sep 1, 2020 at 10:44 AM Alexey Goncharuk 
wrote:

> Ivan,
>
> Thank you for reminding me about the dynamic schema. I've updated the IEP
> draft with more details on the approach, hopefully now it's more clear. I
> think we will be able to take the best from both fixed-schema and
> schemaless approaches.
>
> вт, 1 сент. 2020 г. в 14:31, Ivan Pavlukhin :
>
> > Hi Val,
> >
> > Thank you for raising a discussion about this significant proposal!
> > The subject looks very significant and can greatly affect product
> > spirit and user experience.
> >
> > While I generally think that schema-first is a good idea, I would love
> > to see a thorough approaches comparison section. As we know different
> > databases treat data schema differently. And each way has benefits and
> > drawbacks. Additionally to schemeless and schema-first approaches I
> > remember talks about "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,
> > >
> > > Generally speaking, I believe that the schema-first approach natively
> > > addresses the issue if duplicate fields in key and value objects,
> because
> > > schema will be created for a cache, not for an object, as it happens
> now.
> > > Basically, the schema will define whether there is a primary key or
> not,
> > > and which fields are included in case there is one. Any API that we
> would
> > > have must be compliant with this, so it becomes fairly easy to work
> with
> > > data as with a set of records, rather than key-value pairs.
> > >
> > > However, could you please elaborate on the relation between Ignite and
> > ORM?
> > > Is there a use case for Hibernate running on top of Ignite (I haven't
> > seen
> > > one so far)? If so, what is missing exactly on the Ignite side to
> support
> > > this? In my understanding, all you need is SQL API which we already
> have.
> > > Am I missing something?
> > >
> > > -Val
> > >
> > > On Mon, Aug 31, 2020 at 2:08 PM Denis Magda  wrote:
> > >
> > >> Val,
> > >>
> > >> I would propose adding another point to the motivations list which is
> > >> related to the ORM frameworks such as Spring Data, Hibernate,
> Micronaut
> > >> and
> > >> many others.
> > >>
> > >> Presently, the storage engine requires to distinguish key objects from
> > >> the
> > >> value ones that complicate the usage of Ignite with those ORM
> frameworks
> > >> (especially if a key object comprises several fields). More on this
> can
> > >> be
> > >> found here:
> > >>
> > >>
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Key-and-Value-fields-with-same-name-and-SQL-DML-td47557.html
> > >>
> > >> It will be nice if the new schema-first approach allows us to work
> with
> > a
> > >> single entity object when it comes to the ORMs. With no need to split
> > the
> > >> entity into a key and value. Just want to be sure that the Ignite 3.0
> > has
> > >> all the essential public APIs that would support the single-entity
> based
> > >> 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-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 any immediate
> > thoughts,
> > >> > suggestions, or objections.
> > >> >
> > >> > -Val
> > >> >
> > >>
> > >
> >
> >
> > --
> >
> > Best regards,
> > Ivan Pavlukhin
> >
>

Re: IEP-54: Schema-first approach for 3.0

[Denis Magda]

>
> However, could you please elaborate on the relation between Ignite and ORM?
> Is there a use case for Hibernate running on top of Ignite (I haven't seen
> one so far)? If so, what is missing exactly on the Ignite side to support
> this? In my understanding, all you need is SQL API which we already have.
> Am I missing something?


Good point, yes, if all the ORM integrations use Ignite SQL APIs
internally, then they can easily translate an Entity object into an
INSERT/UPDATE statement that lists all the object's fields. Luckily, our
Spring Data integration is already based on the Ignite SQL APIs and needs
to be improved once the schema-first approach is supported. That would
solve a ton of usability issues.

I would revise the Hibernate integration as well during the Ignite 3.0 dev
phase. Can't say if it's used a lot but Spring Data is getting traction for
sure.

@Michael Pollind, I'll loop you in as long as you've started working on the
Ignite support for Micornaut Data
 and
came across some challenges. Just watch this discussion. That's what is
coming in Ignite 3.0.


-
Denis


On Mon, Aug 31, 2020 at 5:11 PM Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Hi Denis,
>
> Generally speaking, I believe that the schema-first approach natively
> addresses the issue if duplicate fields in key and value objects, because
> schema will be created for a cache, not for an object, as it happens now.
> Basically, the schema will define whether there is a primary key or not,
> and which fields are included in case there is one. Any API that we would
> have must be compliant with this, so it becomes fairly easy to work with
> data as with a set of records, rather than key-value pairs.
>
> However, could you please elaborate on the relation between Ignite and ORM?
> Is there a use case for Hibernate running on top of Ignite (I haven't seen
> one so far)? If so, what is missing exactly on the Ignite side to support
> this? In my understanding, all you need is SQL API which we already have.
> Am I missing something?
>
> -Val
>
> On Mon, Aug 31, 2020 at 2:08 PM Denis Magda  wrote:
>
> > Val,
> >
> > I would propose adding another point to the motivations list which is
> > related to the ORM frameworks such as Spring Data, Hibernate, Micronaut
> and
> > many others.
> >
> > Presently, the storage engine requires to distinguish key objects from
> the
> > value ones that complicate the usage of Ignite with those ORM frameworks
> > (especially if a key object comprises several fields). More on this can
> be
> > found here:
> >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Key-and-Value-fields-with-same-name-and-SQL-DML-td47557.html
> >
> > It will be nice if the new schema-first approach allows us to work with a
> > single entity object when it comes to the ORMs. With no need to split the
> > entity into a key and value. Just want to be sure that the Ignite 3.0 has
> > all the essential public APIs that would support the single-entity based
> > 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-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 any immediate thoughts,
> > > suggestions, or objections.
> > >
> > > -Val
> > >
> >
>