ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Юрий <jury.gerzhedow...@gmail.com>
Subject Re: IEP-54: Schema-first approach for 3.0
Date Thu, 26 Nov 2020 11:32:36 GMT
A little bit my thoughts about unsigned types:

1. Seems we may support unsign types
2. It requires adding new types to the internal representation, protocol,
e.t.c.
3. internal representation should be the same as we keep sign types. So it
will not requires more memory
4. User should be aware of specifics such types for platforms which not
support unsigned types. For example, a user could derive -6 value in Java
for 250 unsigned byte value (from bits perspective will be right). I think
We shouldn't use more wide type for such cases, especially it will be bad
for unsigned long when we require returns BigInteger type.
5. Possible it requires some suffix/preffix for new types like a '250u' -
it means that 250 is an unsigned value type.
6. It requires a little bit more expensive comparison logic for indexes
7. It requires new comparison logic for expressions. I think it not
possible for the current H2 engine and probably possible for the new
Calcite engine. Need clarification from anybody who involved in this part

WDYT?

вт, 24 нояб. 2020 г. в 18:36, Alexey Goncharuk <alexey.goncharuk@gmail.com>:

> 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
> > > >
> > >
> >
>


-- 
Живи с улыбкой! :D

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