Folks,
I updated the IEP to contain the missing pieces; actually, most of the
questions here were covered by the text. Please let me know if there is
something still missing or unclear.
чт, 31 дек. 2020 г. в 12:48, Alexey Goncharuk :
> Mikhail and Igniters,
>
> Thanks for your comments. The questions are reasonable, though I think all
> concerns are addressed by the IEP as Val mentioned. I will update the
> document according to your questions in the following week or so, so we can
> have a constructive discussion further.
>
> ср, 30 дек. 2020 г. в 11:45, Michael Cherkasov <
> michael.cherka...@gmail.com>:
>
>> Hi Val, Andrey,
>>
>> thank you for clarifying.
>>
>> I still have a few comments.
>>
>> 1. one table == one schema. KV vs SQL:
>> Looks like all agreed that KV is just a special case of a regular table
>> with (blob,blob) schema.
>> I worry about the case when the user starts from KV case and later will
>> try
>> to expand it and try to leverage SQL for the existing KV table it won't be
>> able to do so and will require to reload data. which isn't convenient and
>> sometimes not even possible. Is it possible to extract a new field from
>> (blob, blob) schema and apply index on it?
>>
>> 2. Could you please also list all ways of schema definition in the IEP? It
>> significant change and I bet the main point of this IEP, everyone hates
>> QueryEntities, they are difficult to manage and in general, it's very
>> confusing to have a data model(schemas) and node/cluster configuration in
>> one place.
>>
>> So there will be SchemaBuilder and SQL to define schemas, but Andrey also
>> mentioned annotations.
>>
>> I personally against configuration via annotations, while it's convenient
>> for development, it difficult to manage because different classes can be
>> deployed on different clients/servers nodes and it can lead to
>> unpredictable results.
>>
>> 3. IEP doesn't mention field type changes, only drop/add fields. Field
>> type
>> changes are extremely painful right now(if even possible), so it would be
>> nice if some scenarios would be supported(like int8->int16, or
>> int8->String).
>>
>> 4. got it, I thought IEP will have more details about the implementation.
>> I've seen Andrey even sent benchmark results for a new serialization, will
>> ping him about this.
>>
>> 5. Thanks for the clarification. I had a wrong understanding of strick
>> mode.
>>
>>
>> вт, 29 дек. 2020 г. в 19:32, Valentin Kulichenko <
>> valentin.kuliche...@gmail.com>:
>>
>> > Hi Mike,
>> >
>> > Thanks for providing your feedback. Please see my comments below.
>> >
>> > I would also encourage you to go through the IEP-54 [1] - it has a lot
>> of
>> > detail on the topic.
>> >
>> > [1]
>> >
>> >
>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-54%3A+Schema-first+Approach
>> >
>> > -Val
>> >
>> > On Mon, Dec 28, 2020 at 11:22 PM Michael Cherkasov <
>> > michael.cherka...@gmail.com> wrote:
>> >
>> > > Hi all,
>> > >
>> > > I reviewed the mail thread and proposal page and I still don't fully
>> > > understand what is going to be changed, I would really appreciate it
>> if
>> > you
>> > > will answer a few questions:
>> > >
>> > > 1. Are you going to leave only one schema per cache? if so, will be
>> there
>> > > an option to have a table with arbitrary objects(pure KV case)?
>> > >
>> >
>> > My opinion is that KV case should be natively supported. I think this
>> still
>> > needs to be thought over, my current view on this is that we should have
>> > separate APIs for KV and more generic storages. KV storage can be
>> > implemented as a "table" with two BLOB fields where we will store
>> > serialized key-value pairs. That would imply deserialization on read,
>> but I
>> > believe this is OK for KV use cases. I'm happy to hear other ideas
>> though
>> > :)
>> >
>> >
>> > > 2. What options will Apache Ignite 3.0 have to define schema?
>> > SchemaBuilder
>> > > and SQL only? Is there an option to put the schema definition to the
>> > > configuration?(I really don't like this, I would prefer to have
>> > > separate scripts to create schemas)
>> > >
>> >
>> > There will be no such thing as a static configuration in the first
>> place.
>> > Tables and schemas are created in runtime. Even if there is a file
>> provided
>> > on node startup, this file is only applied in the scope of the 'start'
>> > operation. All configurations will be stored in a meta storage
>> available to
>> > all nodes, as opposed to individual files.
>> >
>> >
>> > > 3. Is there a way to change field type? if yes, can it be done in
>> > runtime?
>> > >
>> >
>> > Absolutely! IEP-54 has a whole section about schema evolution.
>> >
>> >
>> > > 4. Looks like BinaryMarshaller is going to be re-worked too, is there
>> any
>> > > IEP for this?
>> > >
>> >
>> > BinaryMarshaller as a tool for arbitrary object serialization will be
>> gone,
>> > but we will reuse a lot of its concept to implement an internal tuple
>> > serialization mechanism. IEP-54 has the descri
