ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexey Goncharuk <alexey.goncha...@gmail.com>
Subject Re: IEP-54: Schema-first approach for 3.0
Date Tue, 24 Nov 2020 15:36:17 GMT
Actually, we can support comparisons in 3.0: once we the actual type
information, we can make proper runtime adjustments and conversions to
treat those values as unsigned - it will be just a bit more expensive.

вт, 24 нояб. 2020 г. в 18:32, Pavel Tupitsyn <ptupitsyn@apache.org>:

> > SQL range queries it will break
> > WHERE x > y may return wrong results
>
> Yes, range queries, inequality comparisons and so on are broken
> for unsigned data types, I think I mentioned this somewhere above.
>
> Again, in my opinion, we can document that SQL is not supported on those
> types,
> end of story.
>
> On Tue, Nov 24, 2020 at 6:25 PM Alexey Goncharuk <
> alexey.goncharuk@gmail.com>
> wrote:
>
> > Folks, I think this is a reasonable request. I thought about this when I
> > was drafting the IEP, but hesitated to add these types right away.
> >
> > > That is how it works in Ignite since the beginning with .NET and C++ :)
> > I have some doubts that it actually works as expected, it needs some
> > checking (will be glad if my concerns are false):
> >
> >    - It's true that equality check works properly, but for SQL range
> >    queries it will break unless some special care is taken on Java side:
> > for
> >    u8 255 > 10, but in Java (byte)255 will be converted to -1, which will
> >    break the comparison. Since we don't have unsigned types now, I doubt
> it
> >    works.
> >    - There is an obvious cross-platform data loss when "intuitive" type
> >    mapping is used by a user (u8 corresponds to byte type in .NET, but to
> >    avoid values loss, a user will have to use short type in Java, and
> > Ignite
> >    will also need to take care of the range check during serialization).
> I
> >    think we can even allow to try to deserialize a value into arbitrary
> > type,
> >    but throw an exception if the range is out of bounds.
> >
> > Overall, I agree with Andrey's comments.
> > Andrey, do you mind updating the IEP once all the details are settled
> here?
> >
> > вт, 24 нояб. 2020 г. в 18:19, Andrey Mashenkov <
> andrey.mashenkov@gmail.com
> > >:
> >
> > > Pavel,
> > >
> > > I believe uLong values beyond 2^63 can't be treated correctly for now
> > > (WHERE x > y may return wrong results)
> > >
> > > I think we could make "true" support for unsigned types, but they will
> > have
> > > limitations on the Java side.
> > > Thus, the one will not be able to map uint64 to Java long primitive,
> but
> > to
> > > BigInteger only.
> > > As for indices, we could read uint64 to Java long, but treat negative
> > > values in a different way to preserve correct ordering.
> > >
> > > These limitations will affect only mixed environments when .Net and
> Java
> > > used to access the data.
> > > Will this solution address your issues?
> > >
> > >
> > > On Tue, Nov 24, 2020 at 5:45 PM Pavel Tupitsyn <ptupitsyn@apache.org>
> > > wrote:
> > >
> > > > > That way is impossible.
> > > >
> > > > That is how it works in Ignite since the beginning with .NET and C++
> :)
> > > > You can use unsigned primitives as cache keys and values, as fields
> and
> > > > properties,
> > > > and in SQL queries (even in WHERE x=y clauses) - it works
> transparently
> > > for
> > > > the users.
> > > > Java side knows nothing and treats those values as corresponding
> signed
> > > > types.
> > > >
> > > > However, this abstraction leaks in some cases only because there are
> no
> > > > corresponding type ids.
> > > > That is why I'm proposing a very simple change to the protocol - add
> > type
> > > > ids, but handle them the same way as signed counterparts.
> > > >
> > > >
> > > > On Tue, Nov 24, 2020 at 5:00 PM Andrey Mashenkov <
> > > > andrey.mashenkov@gmail.com>
> > > > wrote:
> > > >
> > > > > Pavel,
> > > > >
> > > > > - Treat uLong as long in Java (bitwise representation is the same)
> > > > >
> > > > > That way is impossible.
> > > > >
> > > > > Assume, you have a .NET class with a uByte field and map it to
> > 'uint8'
> > > > > column.
> > > > > Then you set the field value to "250" and put the object into a
> > table,
> > > > > field value perfectly fits to a single byte 'int8' column.
> > > > > But in Java you can't deserialize it to directly the Java object
> > field
> > > of
> > > > > 'byte' type, so we should map uint8 type to Java 'short' type
> > > > > because the one expected to see "250" as a value which doesn't fit
> to
> > > the
> > > > > signed type.
> > > > > For uLong the one will need a BigInteger field in Java.
> > > > >
> > > > > SQL index either can't treat column value as Java 'byte' as is,
> > because
> > > > > after reading you will get a negative value, so it should be cast
> to
> > > > short
> > > > > at first. (converted to BigInteger for uint64)
> > > > > So, index on signed type will require a different comparator.
> > > > >
> > > > > That way doesn't look simpler.
> > > > >
> > > > > On Tue, Nov 24, 2020 at 4:23 PM Pavel Tupitsyn <
> ptupitsyn@apache.org
> > >
> > > > > wrote:
> > > > >
> > > > > > Andrey,
> > > > > >
> > > > > > I don't think range narrowing is a good idea.
> > > > > > Do you see any problems with the simple approach I described?
> > > > > >
> > > > > >
> > > > > > On Tue, Nov 24, 2020 at 4:01 PM Andrey Mashenkov <
> > > > > > andrey.mashenkov@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Pavel,
> > > > > > >
> > > > > > > If you are ok with narrowing range for unsigned types then we
> > could
> > > > > add a
> > > > > > > constraint for unsigned types on schema level (like nullability
> > > flag)
> > > > > > > and treat them as signed types in storage.
> > > > > > >
> > > > > > > We are going with a separate storage type-system and binary
> > > protocol
> > > > > > > type-system, however most of type will match 1 to 1 with
> storage
> > > > > (native)
> > > > > > > type.
> > > > > > > On .Net side you will either have a separate type id or treat
> > > > > serialized
> > > > > > > value regarding a schema (signed or unsigned flag).
> > > > > > >
> > > > > > > Igor,
> > > > > > >
> > > > > > > I'm not sure users can ever foresee the consequences of using
> > > > unsigned
> > > > > > > types.
> > > > > > >
> > > > > > > Assume, a user used to unsigned types perfectly works with some
> > > > > database,
> > > > > > > then he turns into Ignite successor confession with our
> "native"
> > > > > > > unsigned-types support.
> > > > > > > But later, he finds that he can use the power of Ignite Compute
> > on
> > > > Java
> > > > > > for
> > > > > > > some tasks or a new app.
> > > > > > > Finally, the user will either fail to use his unsigned data on
> > Java
> > > > due
> > > > > > or
> > > > > > > face performance issues due to natural Java type system
> > limitations
> > > > > e.g.
> > > > > > > conversion uLong to BigInteger.
> > > > > > >
> > > > > > > I believe that natively supported types with possible value
> > ranges
> > > > and
> > > > > > > limitations should be known.
> > > > > > > So, the only question is what trade-off we found acceptable:
> > > > narrowing
> > > > > > > unsigned type range or use types of wider range on systems like
> > > Java.
> > > > > > >
> > > > > > > On Tue, Nov 24, 2020 at 3:25 PM Igor Sapego <
> isapego@apache.org>
> > > > > wrote:
> > > > > > >
> > > > > > > > Actually, I think it is not so hard to implement comparison
> of
> > > > > unsigned
> > > > > > > > numbers in
> > > > > > > > SQL even in Java, so it does not seem to be a big issue from
> my
> > > > > > > > perspective.
> > > > > > > >
> > > > > > > > Now to the usage of unsigned types from Java - I think, if a
> > user
> > > > > uses
> > > > > > > > unsigned type
> > > > > > > > in a schema and is going to interact with it from Java he
> knows
> > > > what
> > > > > he
> > > > > > > is
> > > > > > > > doing.
> > > > > > > >
> > > > > > > > Mostly they are for use from platforms where they have native
> > > > support
> > > > > > and
> > > > > > > > widely
> > > > > > > > used, like in C++ or .NET, where users currently have to
> make a
> > > > > manual
> > > > > > > type
> > > > > > > > casting
> > > > > > > > or even just stop using unsigned types when they use Ignite.
> > > > > > > >
> > > > > > > > Best Regards,
> > > > > > > > Igor
> > > > > > > >
> > > > > > > >
> > > > > > > > On Tue, Nov 24, 2020 at 3:06 PM Pavel Tupitsyn <
> > > > ptupitsyn@apache.org
> > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Andrey,
> > > > > > > > >
> > > > > > > > > I think it is much simpler:
> > > > > > > > > - Add protocol support for those types (basically, just add
> > > more
> > > > > type
> > > > > > > > ids)
> > > > > > > > > - Treat uLong as long in Java (bitwise representation is
> the
> > > > same)
> > > > > > > > >
> > > > > > > > > ANSI SQL does not have unsigned integers, so we can simply
> > say
> > > > that
> > > > > > > > > unsigned value relative comparison is not supported in SQL
> > > > > (equality
> > > > > > > will
> > > > > > > > > work).
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Tue, Nov 24, 2020 at 2:40 PM Andrey Mashenkov <
> > > > > > > > > andrey.mashenkov@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Thanks, Pavel and Igor.
> > > > > > > > > >
> > > > > > > > > > I like your ideas to have i8 or int8 instead of Integer.
> > > > > > > > > > But the naming doesn't address the issue.
> > > > > > > > > >
> > > > > > > > > > I agree internal types should be portable across
> different
> > > > > systems
> > > > > > > with
> > > > > > > > > and
> > > > > > > > > > without unsigned type support.
> > > > > > > > > > The only issue here is that unsigned types cover
> different
> > > > > ranges.
> > > > > > > > > >
> > > > > > > > > > Let's assume we want to introduce a uLong.
> > > > > > > > > > It doesn't look like a big deal to add uLong type support
> > at
> > > > > > storage
> > > > > > > > > level
> > > > > > > > > > and fit it to a 8 bytes and then use it in e.g. .Net
> only.
> > > > > > > > > > But how we could support it in e.g. Java?
> > > > > > > > > >
> > > > > > > > > > Let's keep in mind Long range is about (2^-63 .. 2^63)
> and
> > > > uLong
> > > > > > > range
> > > > > > > > is
> > > > > > > > > > (0 .. 2^64)
> > > > > > > > > > 1. The first option is to restrict range to (0 .. 2^63).
> > This
> > > > > > allows
> > > > > > > to
> > > > > > > > > use
> > > > > > > > > > signed in e.g.
> > > > > > > > > > Java with no conversion, but doesn't look like a 'real'
> > > > unsigned
> > > > > > > uLong
> > > > > > > > > > support. Things go worse when the user will use uByte, as
> > > > > > limitation
> > > > > > > > can
> > > > > > > > > > make uByte totally unusable.
> > > > > > > > > >
> > > > > > > > > > 2. The second one is to map unsigned types to a type of
> > wider
> > > > > type
> > > > > > > and
> > > > > > > > > add
> > > > > > > > > > a constraint for negative values. E.g. uLong to
> BigInteger.
> > > > > > > > > > So, we can't use primitive Java type for Long here.
> > However,
> > > it
> > > > > is
> > > > > > > > still
> > > > > > > > > > possible to store uLong in 8 bytes, but have a special
> > > > comparator
> > > > > > for
> > > > > > > > > > unsigned types to avoid unwanted deserialization.
> > > > > > > > > >
> > > > > > > > > > WDYT?
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Tue, Nov 24, 2020 at 2:04 PM Pavel Tupitsyn <
> > > > > > ptupitsyn@apache.org
> > > > > > > >
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Agree, let's get rid of "long, short, byte" in the
> > protocol
> > > > > > > > definition.
> > > > > > > > > > >
> > > > > > > > > > > We can use Rust style, which is concise and
> unambiguous:
> > > > > > > > > > > i8, u8, i16, u16, etc
> > > > > > > > > > >
> > > > > > > > > > > On Tue, Nov 24, 2020 at 1:58 PM Igor Sapego <
> > > > > isapego@apache.org>
> > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Pavel,
> > > > > > > > > > > >
> > > > > > > > > > > > I totally support that. Also, if we are aiming for
> > > > > > > > > > > > stronger platform-independance,
> > > > > > > > > > > > in our schemas we may want to support bit-notation
> > > (int32,
> > > > > > > uint64)?
> > > > > > > > > For
> > > > > > > > > > > > example
> > > > > > > > > > > > "long" can mean a different type on different
> platforms
> > > and
> > > > > > it's
> > > > > > > > easy
> > > > > > > > > > to
> > > > > > > > > > > > confuse
> > > > > > > > > > > > them (happens often when using ODBC for example).
> > > > > > > > > > > >
> > > > > > > > > > > > Best Regards,
> > > > > > > > > > > > Igor
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On Tue, Nov 24, 2020 at 1:34 PM Pavel Tupitsyn <
> > > > > > > > ptupitsyn@apache.org
> > > > > > > > > >
> > > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > Igniters,
> > > > > > > > > > > > >
> > > > > > > > > > > > > I think we should support unsigned data types:
> > > > > > > > > > > > > uByte, uShort, uInt, uLong
> > > > > > > > > > > > >
> > > > > > > > > > > > > Java does not have them, but many other languages
> do,
> > > > > > > > > > > > > and with the growing number of thin clients this is
> > > > > > important.
> > > > > > > > > > > > >
> > > > > > > > > > > > > For example, in current Ignite.NET implementation
> we
> > > > store
> > > > > > > > unsigned
> > > > > > > > > > > > values
> > > > > > > > > > > > > as signed internally,
> > > > > > > > > > > > > but this is a huge pain when it comes to metadata,
> > > binary
> > > > > > > > objects,
> > > > > > > > > > etc.
> > > > > > > > > > > > > (it is easy to deserialize int as uint when you
> have
> > a
> > > > > class,
> > > > > > > but
> > > > > > > > > not
> > > > > > > > > > > > with
> > > > > > > > > > > > > BinaryObject.GetField)
> > > > > > > > > > > > >
> > > > > > > > > > > > > Any objections?
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Tue, Nov 24, 2020 at 12:28 PM Andrey Mashenkov <
> > > > > > > > > > > > > andrey.mashenkov@gmail.com> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Denis,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Good point. Both serializers use reflection API.
> > > > > > > > > > > > > > However, we will allow users to configure static
> > > schema
> > > > > > along
> > > > > > > > > with
> > > > > > > > > > > > > 'strict'
> > > > > > > > > > > > > > schema mode, we still need to validate user
> classes
> > > on
> > > > > > client
> > > > > > > > > nodes
> > > > > > > > > > > > > against
> > > > > > > > > > > > > > the latest schema in the grid  and reflection API
> > is
> > > > the
> > > > > > only
> > > > > > > > way
> > > > > > > > > > to
> > > > > > > > > > > do
> > > > > > > > > > > > > it.
> > > > > > > > > > > > > > One can find a few articles on the internet on
> how
> > to
> > > > > > enable
> > > > > > > > > > > reflection
> > > > > > > > > > > > > in
> > > > > > > > > > > > > > GraalVM.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I'll create a task for supporting GraalVM, and
> > maybe
> > > > > > someone
> > > > > > > > who
> > > > > > > > > is
> > > > > > > > > > > > > > familiar with GraalVM will suggest a solution or
> a
> > > > proper
> > > > > > > > > > workaround.
> > > > > > > > > > > > Or
> > > > > > > > > > > > > > I'll do it a bit later.
> > > > > > > > > > > > > > If no workaround is found, we could allow users
> to
> > > > write
> > > > > > it's
> > > > > > > > own
> > > > > > > > > > > > > > serializer, but I don't think it is a good idea
> to
> > > > expose
> > > > > > any
> > > > > > > > > > > internal
> > > > > > > > > > > > > > classes to the public.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Tue, Nov 24, 2020 at 2:55 AM Denis Magda <
> > > > > > > dmagda@apache.org
> > > > > > > > >
> > > > > > > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Andrey, thanks for the update,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Does any of the serializers take into
> > consideration
> > > > the
> > > > > > > > > > > > > > > native-image-generation feature of GraalVM?
> > > > > > > > > > > > > > >
> > > > https://www.graalvm.org/reference-manual/native-image/
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > With the current binary marshaller, we can't
> even
> > > > > > generate
> > > > > > > a
> > > > > > > > > > native
> > > > > > > > > > > > > image
> > > > > > > > > > > > > > > for the code using our thin client APIs.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -
> > > > > > > > > > > > > > > Denis
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Mon, Nov 23, 2020 at 4:39 AM Andrey
> Mashenkov
> > <
> > > > > > > > > > > > > > > andrey.mashenkov@gmail.com>
> > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Hi Igniters,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I'd like to continue discussion of IEP-54
> > > > > (Schema-first
> > > > > > > > > > > approach).
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Hope everyone who is interested had a chance
> to
> > > get
> > > > > > > > familiar
> > > > > > > > > > with
> > > > > > > > > > > > the
> > > > > > > > > > > > > > > > proposal [1].
> > > > > > > > > > > > > > > > Please, do not hesitate to ask questions and
> > > share
> > > > > your
> > > > > > > > > ideas.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I've prepared a prototype of serializer [2]
> for
> > > the
> > > > > > data
> > > > > > > > > layout
> > > > > > > > > > > > > > described
> > > > > > > > > > > > > > > > in the proposal.
> > > > > > > > > > > > > > > > In prototy, I compared 2 approaches to
> > > > (de)serialize
> > > > > > > > objects,
> > > > > > > > > > the
> > > > > > > > > > > > > first
> > > > > > > > > > > > > > > one
> > > > > > > > > > > > > > > > uses java reflection/unsafe API and similar
> to
> > > one
> > > > we
> > > > > > > > already
> > > > > > > > > > use
> > > > > > > > > > > > in
> > > > > > > > > > > > > > > Ignite
> > > > > > > > > > > > > > > > and the second one generates serializer for
> > > > > particular
> > > > > > > user
> > > > > > > > > > class
> > > > > > > > > > > > and
> > > > > > > > > > > > > > > uses
> > > > > > > > > > > > > > > > Janino library for compilation.
> > > > > > > > > > > > > > > > Second one shows better results in
> benchmarks.
> > > > > > > > > > > > > > > > I think we can go with it as default
> serializer
> > > and
> > > > > > have
> > > > > > > > > > > > > > reflection-based
> > > > > > > > > > > > > > > > implementation as a fallback if someone will
> > have
> > > > > > issues
> > > > > > > > with
> > > > > > > > > > the
> > > > > > > > > > > > > first
> > > > > > > > > > > > > > > > one.
> > > > > > > > > > > > > > > > WDYT?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > There are a number of tasks under the
> umbrella
> > > > ticket
> > > > > > [3]
> > > > > > > > > > waiting
> > > > > > > > > > > > for
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > assignee.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > BTW, I'm going to create more tickets for
> > schema
> > > > > > manager
> > > > > > > > > modes
> > > > > > > > > > > > > > > > implementation, but would like to clarify
> some
> > > > > details.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I thought schemaManager on each node should
> > held:
> > > > > > > > > > > > > > > >   1. Local mapping of "schema version" <-->
> > > > validated
> > > > > > > local
> > > > > > > > > > > > key/value
> > > > > > > > > > > > > > > > classes pair.
> > > > > > > > > > > > > > > >   2. Cluster-wide schema changes history.
> > > > > > > > > > > > > > > > On the client side. Before any key-value API
> > > > > operation
> > > > > > we
> > > > > > > > > > should
> > > > > > > > > > > > > > > validate a
> > > > > > > > > > > > > > > > schema for a given key-value pair.
> > > > > > > > > > > > > > > > If there is no local-mapping exists for a
> given
> > > > > > key-value
> > > > > > > > > pair
> > > > > > > > > > or
> > > > > > > > > > > > if
> > > > > > > > > > > > > a
> > > > > > > > > > > > > > > > cluster wide schema has a more recent version
> > > then
> > > > > the
> > > > > > > > > > key-value
> > > > > > > > > > > > pair
> > > > > > > > > > > > > > > > should be validated against the latest
> version
> > > and
> > > > > > local
> > > > > > > > > > mapping
> > > > > > > > > > > > > should
> > > > > > > > > > > > > > > be
> > > > > > > > > > > > > > > > updated/actualized.
> > > > > > > > > > > > > > > > If an object doesn't fit to the latest schema
> > > then
> > > > it
> > > > > > > > depends
> > > > > > > > > > on
> > > > > > > > > > > > > schema
> > > > > > > > > > > > > > > > mode: either fail the operation ('strict'
> mode)
> > > or
> > > > a
> > > > > > new
> > > > > > > > > > mapping
> > > > > > > > > > > > > should
> > > > > > > > > > > > > > > be
> > > > > > > > > > > > > > > > created and a new schema version should be
> > > > propagated
> > > > > > to
> > > > > > > > the
> > > > > > > > > > > > cluster.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On the server side we usually have no
> key-value
> > > > > classes
> > > > > > > and
> > > > > > > > > we
> > > > > > > > > > > > > operate
> > > > > > > > > > > > > > > with
> > > > > > > > > > > > > > > > tuples.
> > > > > > > > > > > > > > > > As schema change history is available and a
> > tuple
> > > > has
> > > > > > > > schema
> > > > > > > > > > > > version,
> > > > > > > > > > > > > > > then
> > > > > > > > > > > > > > > > it is possible to upgrade any received tuple
> to
> > > the
> > > > > > last
> > > > > > > > > > version
> > > > > > > > > > > > > > without
> > > > > > > > > > > > > > > > desialization.
> > > > > > > > > > > > > > > > Thus we could allow nodes to send key-value
> > pairs
> > > > of
> > > > > > > > previous
> > > > > > > > > > > > > versions
> > > > > > > > > > > > > > > (if
> > > > > > > > > > > > > > > > they didn't receive a schema update yet)
> > without
> > > > > > > reverting
> > > > > > > > > > schema
> > > > > > > > > > > > > > changes
> > > > > > > > > > > > > > > > made by a node with newer classes.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Alex, Val, Ivan did you mean the same?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > [1]
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-54%3A+Schema-first+Approach
> > > > > > > > > > > > > > > > [2]
> > > > > > > > > > > > >
> > > > > > > >
> > > https://github.com/apache/ignite/tree/ignite-13618/modules/commons
> > > > > > > > > > > > > > > > [3]
> > > > > https://issues.apache.org/jira/browse/IGNITE-13616
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Thu, Sep 17, 2020 at 9:21 AM Ivan
> Pavlukhin
> > <
> > > > > > > > > > > > vololo100@gmail.com>
> > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Folks,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Please do not ignore history. We had a
> thread
> > > [1]
> > > > > > with
> > > > > > > > many
> > > > > > > > > > > > bright
> > > > > > > > > > > > > > > > > ideas. We can resume it.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > [1]
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/Applicability-of-term-cache-to-Apache-Ignite-td36541.html
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 2020-09-10 0:08 GMT+03:00, Denis Magda <
> > > > > > > > dmagda@apache.org
> > > > > > > > > >:
> > > > > > > > > > > > > > > > > > Val, makes sense, thanks for explaining.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Agree that we need to have a separate
> > > > discussion
> > > > > > > thread
> > > > > > > > > for
> > > > > > > > > > > the
> > > > > > > > > > > > > > > "table"
> > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > "cache" terms substitution. I'll
> appreciate
> > > it
> > > > if
> > > > > > you
> > > > > > > > > start
> > > > > > > > > > > the
> > > > > > > > > > > > > > > thread
> > > > > > > > > > > > > > > > > > sharing pointers to any relevant IEPs and
> > > > > reasoning
> > > > > > > > > behind
> > > > > > > > > > > the
> > > > > > > > > > > > > > > > suggested
> > > > > > > > > > > > > > > > > > change.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -
> > > > > > > > > > > > > > > > > > Denis
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Tue, Sep 8, 2020 at 6:01 PM Valentin
> > > > > Kulichenko
> > > > > > <
> > > > > > > > > > > > > > > > > > valentin.kulichenko@gmail.com> wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >> Hi Denis,
> > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > >> I guess the wording in the IEP is a
> little
> > > bit
> > > > > > > > > confusing.
> > > > > > > > > > > All
> > > > > > > > > > > > it
> > > > > > > > > > > > > > > means
> > > > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > >> that you should not create nested POJOs,
> > but
> > > > > > rather
> > > > > > > > > inline
> > > > > > > > > > > > > fields
> > > > > > > > > > > > > > > > into a
> > > > > > > > > > > > > > > > > >> single POJO that is mapped to a
> particular
> > > > > schema.
> > > > > > > In
> > > > > > > > > > other
> > > > > > > > > > > > > words,
> > > > > > > > > > > > > > > > > nested
> > > > > > > > > > > > > > > > > >> POJOs are not supported.
> > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > >> Alex, is this correct? Please let me
> know
> > if
> > > > I'm
> > > > > > > > missing
> > > > > > > > > > > > > > something.
> > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > >> As for the "cache" term, I agree that it
> > is
> > > > > > > outdated,
> > > > > > > > > but
> > > > > > > > > > > I'm
> > > > > > > > > > > > > not
> > > > > > > > > > > > > > > sure
> > > > > > > > > > > > > > > > > >> what we can replace it with. "Table" is
> > > > tightly
> > > > > > > > > associated
> > > > > > > > > > > > with
> > > > > > > > > > > > > > SQL,
> > > > > > > > > > > > > > > > but
> > > > > > > > > > > > > > > > > >> SQL is optional in our case. Do you want
> > to
> > > > > > create a
> > > > > > > > > > > separate
> > > > > > > > > > > > > > > > discussion
> > > > > > > > > > > > > > > > > >> about this?
> > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > >> -Val
> > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > >> On Tue, Sep 8, 2020 at 4:37 PM Denis
> > Magda <
> > > > > > > > > > > dmagda@apache.org
> > > > > > > > > > > > >
> > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > >>> Val,
> > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > >>> I've checked the IEP again and have a
> few
> > > > > > > questions.
> > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > >>> Arbitrary nested objects and
> collections
> > > are
> > > > > not
> > > > > > > > > allowed
> > > > > > > > > > as
> > > > > > > > > > > > > > column
> > > > > > > > > > > > > > > > > >>> values.
> > > > > > > > > > > > > > > > > >>> > Nested POJOs should either be inlined
> > > into
> > > > > > > schema,
> > > > > > > > or
> > > > > > > > > > > > stored
> > > > > > > > > > > > > as
> > > > > > > > > > > > > > > > BLOBs
> > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > >>> Could you provide a DDL code snippet
> > > showing
> > > > > how
> > > > > > > the
> > > > > > > > > > > inlining
> > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > POJOs
> > > > > > > > > > > > > > > > > >>> is
> > > > > > > > > > > > > > > > > >>> supposed to work?
> > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > >>> Also, we keep using the terms "cache"
> and
> > > > > "table"
> > > > > > > > > > > throughout
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > IEP.
> > > > > > > > > > > > > > > > > Is
> > > > > > > > > > > > > > > > > >>> it
> > > > > > > > > > > > > > > > > >>> the right time to discuss an alternate
> > name
> > > > > that
> > > > > > > > would
> > > > > > > > > > > > replace
> > > > > > > > > > > > > > > those
> > > > > > > > > > > > > > > > > >>> too?
> > > > > > > > > > > > > > > > > >>> Personally, the "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.kulichenko@gmail.com> wrote:
> > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > >>> > Ivan,
> > > > > > > > > > > > > > > > > >>> >
> > > > > > > > > > > > > > > > > >>> > I see your point. I agree that with
> the
> > > > > > automatic
> > > > > > > > > > updates
> > > > > > > > > > > > we
> > > > > > > > > > > > > > step
> > > > > > > > > > > > > > > > > into
> > > > > > > > > > > > > > > > > >>> the
> > > > > > > > > > > > > > > > > >>> > schema-last territory.
> > > > > > > > > > > > > > > > > >>> >
> > > > > > > > > > > > > > > > > >>> > Actually, if we support automatic
> > > > evolution,
> > > > > we
> > > > > > > can
> > > > > > > > > as
> > > > > > > > > > > well
> > > > > > > > > > > > > > > support
> > > > > > > > > > > > > > > > > >>> > creating a cache without schema and
> > > > inferring
> > > > > > it
> > > > > > > > from
> > > > > > > > > > the
> > > > > > > > > > > > > first
> > > > > > > > > > > > > > > > > >>> > insert.
> > > > > > > > > > > > > > > > > >>> In
> > > > > > > > > > > > > > > > > >>> > other words, we can have both
> > > > "schema-first"
> > > > > > and
> > > > > > > > > > > > > "schema-last"
> > > > > > > > > > > > > > > > modes.
> > > > > > > > > > > > > > > > > >>> >
> > > > > > > > > > > > > > > > > >>> > Alexey, what do you think?
> > > > > > > > > > > > > > > > > >>> >
> > > > > > > > > > > > > > > > > >>> > -Val
> > > > > > > > > > > > > > > > > >>> >
> > > > > > > > > > > > > > > > > >>> > On Mon, Sep 7, 2020 at 5:59 AM Alexey
> > > > > > Goncharuk <
> > > > > > > > > > > > > > > > > >>> > alexey.goncharuk@gmail.com>
> > > > > > > > > > > > > > > > > >>> > wrote:
> > > > > > > > > > > > > > > > > >>> >
> > > > > > > > > > > > > > > > > >>> > > Ivan,
> > > > > > > > > > > > > > > > > >>> > >
> > > > > > > > > > > > > > > > > >>> > > Thank you, I got your concern now.
> As
> > > it
> > > > is
> > > > > > > > mostly
> > > > > > > > > > > > > regarding
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > >>> > > terminology, I am absolutely fine
> > with
> > > > > > changing
> > > > > > > > the
> > > > > > > > > > > name
> > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > whatever
> > > > > > > > > > > > > > > > > >>> fits
> > > > > > > > > > > > > > > > > >>> > > the approach best. Dynamic or
> > evolving
> > > > > schema
> > > > > > > > > sounds
> > > > > > > > > > > > > great. I
> > > > > > > > > > > > > > > > will
> > > > > > > > > > > > > > > > > >>> make
> > > > > > > > > > > > > > > > > >>> > > corresponding changes to the IEP
> once
> > > we
> > > > > > settle
> > > > > > > > on
> > > > > > > > > > the
> > > > > > > > > > > > > name.
> > > > > > > > > > > > > > > > > >>> > >
> > > > > > > > > > > > > > > > > >>> > > пн, 7 сент. 2020 г. в 11:33, Ivan
> > > > > Pavlukhin <
> > > > > > > > > > > > > > > vololo100@gmail.com
> > > > > > > > > > > > > > > > >:
> > > > > > > > > > > > > > > > > >>> > >
> > > > > > > > > > > > > > > > > >>> > > > Hi Val,
> > > > > > > > > > > > > > > > > >>> > > >
> > > > > > > > > > > > > > > > > >>> > > > Thank you for your answer!
> > > > > > > > > > > > > > > > > >>> > > >
> > > > > > > > > > > > > > > > > >>> > > > My understanding is a little bit
> > > > > different.
> > > > > > > > Yes,
> > > > > > > > > > > schema
> > > > > > > > > > > > > > > > evolution
> > > > > > > > > > > > > > > > > >>> > > > definitely should be possible.
> But
> > I
> > > > see
> > > > > a
> > > > > > > main
> > > > > > > > > > > > > difference
> > > > > > > > > > > > > > in
> > > > > > > > > > > > > > > > > "how
> > > > > > > > > > > > > > > > > >>> > > > schema is updated". I treat a
> > common
> > > > SQL
> > > > > > > > approach
> > > > > > > > > > > > > > > schema-first.
> > > > > > > > > > > > > > > > > >>> Schema
> > > > > > > > > > > > > > > > > >>> > > > and data manipulation operations
> > are
> > > > > > clearly
> > > > > > > > > > > separated
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > > >>> enables
> > > > > > > > > > > > > > > > > >>> > > > interesting capabilities, e.g.
> > > > preventing
> > > > > > > > > untended
> > > > > > > > > > > > schema
> > > > > > > > > > > > > > > > changes
> > > > > > > > > > > > > > > > > >>> > > > by
> > > > > > > > > > > > > > > > > >>> > > > mistaken data operations,
> > restricting
> > > > > user
> > > > > > > > > > > permissions
> > > > > > > > > > > > to
> > > > > > > > > > > > > > > > change
> > > > > > > > > > > > > > > > > >>> > > > schema.
> > > > > > > > > > > > > > > > > >>> > > >
> > > > > > > > > > > > > > > > > >>> > > > > Schema-first means that schema
> > > exists
> > > > > in
> > > > > > > > > advance
> > > > > > > > > > > and
> > > > > > > > > > > > > all
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > >>> stored
> > > > > > > > > > > > > > > > > >>> > > data
> > > > > > > > > > > > > > > > > >>> > > > is compliant with it - that's
> > exactly
> > > > > what
> > > > > > is
> > > > > > > > > > > proposed.
> > > > > > > > > > > > > > > > > >>> > > >
> > > > > > > > > > > > > > > > > >>> > > > A schema-last approach mentioned
> in
> > > [1]
> > > > > > also
> > > > > > > > > > assumes
> > > > > > > > > > > > that
> > > > > > > > > > > > > > > > schema
> > > > > > > > > > > > > > > > > >>> > > > exists, but it is inferred from
> > data.
> > > > Is
> > > > > > not
> > > > > > > it
> > > > > > > > > > more
> > > > > > > > > > > > > > similar
> > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > >>> > > > the
> > > > > > > > > > > > > > > > > >>> > > > proposing approach?
> > > > > > > > > > > > > > > > > >>> > > >
> > > > > > > > > > > > > > > > > >>> > > > And I would like to say, that my
> > main
> > > > > > concern
> > > > > > > > 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/~yanlei/courses/CS691LL-f06/papers/SH05.pdf
> > > > > > > > > > > > > > > > > >>> > > >
> > > > > > > > > > > > > > > > > >>> > > > 2020-09-07 0:47 GMT+03:00,
> Valentin
> > > > > > > Kulichenko
> > > > > > > > <
> > > > > > > > > > > > > > > > > >>> > > > valentin.kulichenko@gmail.com>:
> > > > > > > > > > > > > > > > > >>> > > > > Hi Ivan,
> > > > > > > > > > > > > > > > > >>> > > > >
> > > > > > > > > > > > > > > > > >>> > > > > I don't see an issue with that.
> > > > > > > Schema-first
> > > > > > > > > > means
> > > > > > > > > > > > that
> > > > > > > > > > > > > > > > schema
> > > > > > > > > > > > > > > > > >>> exists
> > > > > > > > > > > > > > > > > >>> > > in
> > > > > > > > > > > > > > > > > >>> > > > > advance and all the stored data
> > is
> > > > > > > compliant
> > > > > > > > > with
> > > > > > > > > > > it
> > > > > > > > > > > > -
> > > > > > > > > > > > > > > that's
> > > > > > > > > > > > > > > > > >>> exactly
> > > > > > > > > > > > > > > > > >>> > > > what
> > > > > > > > > > > > > > > > > >>> > > > > is proposed. There are no
> > > > restrictions
> > > > > > > > > > prohibiting
> > > > > > > > > > > > > > changes
> > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > >>> > > > > the
> > > > > > > > > > > > > > > > > >>> > > schema.
> > > > > > > > > > > > > > > > > >>> > > > >
> > > > > > > > > > > > > > > > > >>> > > > > -Val
> > > > > > > > > > > > > > > > > >>> > > > >
> > > > > > > > > > > > > > > > > >>> > > > > On Sat, Sep 5, 2020 at 9:52 PM
> > Ivan
> > > > > > > > Pavlukhin <
> > > > > > > > > > > > > > > > > >>> vololo100@gmail.com>
> > > > > > > > > > > > > > > > > >>> > > > wrote:
> > > > > > > > > > > > > > > > > >>> > > > >
> > > > > > > > > > > > > > > > > >>> > > > >> Alexey,
> > > > > > > > > > > > > > > > > >>> > > > >>
> > > > > > > > > > > > > > > > > >>> > > > >> I am a little bit confused
> with
> > > > > > > terminology.
> > > > > > > > > My
> > > > > > > > > > > > > > > > understanding
> > > > > > > > > > > > > > > > > >>> > conforms
> > > > > > > > > > > > > > > > > >>> > > > >> to a survey [1] (see part X
> Semi
> > > > > > > Structured
> > > > > > > > > > Data).
> > > > > > > > > > > > Can
> > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > >>> > > > >> really
> > > > > > > > > > > > > > > > > >>> > treat
> > > > > > > > > > > > > > > > > >>> > > > >> a "dynamic schema" approach
> as a
> > > > kind
> > > > > of
> > > > > > > > > > > > > "schema-first"?
> > > > > > > > > > > > > > > > > >>> > > > >>
> > > > > > > > > > > > > > > > > >>> > > > >> [1]
> > > > > > > > > > > > > > > > > >>> > > > >>
> > > > > > > > > > > > > > > > > >>> > >
> > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> https://people.cs.umass.edu/~yanlei/courses/CS691LL-f06/papers/SH05.pdf
> > > > > > > > > > > > > > > > > >>> > > > >>
> > > > > > > > > > > > > > > > > >>> > > > >> 2020-09-02 1:53 GMT+03:00,
> Denis
> > > > > Magda <
> > > > > > > > > > > > > > dmagda@apache.org
> > > > > > > > > > > > > > > >:
> > > > > > > > > > > > > > > > > >>> > > > >> >>
> > > > > > > > > > > > > > > > > >>> > > > >> >> 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
> > > > > > > > > > > > > > > > > >>> > > > >> > <
> > > > > > > > > > > > > > > > > >>> >
> > > > > > > > > > > > > > >
> > > > > > > > > >
> > > > > https://micronaut-projects.github.io/micronaut-data/latest/guide/>
> > > > > > > > > > > > > > > > > >>> > > > 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.kulichenko@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 <
> > > > > > > > > > > > > > > > > >>> dmagda@apache.org>
> > > > > > > > > > > > > > > > > >>> > > > 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.kulichenko@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
> > > > > > > > > > > > > > > > > >>> > > > >>
> > > > > > > > > > > > > > > > > >>> > > > >
> > > > > > > > > > > > > > > > > >>> > > >
> > > > > > > > > > > > > > > > > >>> > > >
> > > > > > > > > > > > > > > > > >>> > > > --
> > > > > > > > > > > > > > > > > >>> > > >
> > > > > > > > > > > > > > > > > >>> > > > Best regards,
> > > > > > > > > > > > > > > > > >>> > > > Ivan Pavlukhin
> > > > > > > > > > > > > > > > > >>> > > >
> > > > > > > > > > > > > > > > > >>> > >
> > > > > > > > > > > > > > > > > >>> >
> > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Best regards,
> > > > > > > > > > > > > > > > > Ivan Pavlukhin
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > > Best regards,
> > > > > > > > > > > > > > > > Andrey V. Mashenkov
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > --
> > > > > > > > > > > > > > Best regards,
> > > > > > > > > > > > > > Andrey V. Mashenkov
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Best regards,
> > > > > > > > > > Andrey V. Mashenkov
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Best regards,
> > > > > > > Andrey V. Mashenkov
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best regards,
> > > > > Andrey V. Mashenkov
> > > > >
> > > >
> > >
> > >
> > > --
> > > Best regards,
> > > Andrey V. Mashenkov
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message