Sergi Vladykin created IGNITE-10937:
---
Summary: Support data page scan for JDBC/ODBC
Key: IGNITE-10937
URL: https://issues.apache.org/jira/browse/IGNITE-10937
Project: Ignite
Issue Type
Sergi Vladykin created IGNITE-10798:
---
Summary: Data page scan for ScanQuery, SqlQuery and SqlFieldsQuery
Key: IGNITE-10798
URL: https://issues.apache.org/jira/browse/IGNITE-10798
Project: Ignite
Sergi Vladykin created IGNITE-10431:
---
Summary: Make tests independent of memory size
Key: IGNITE-10431
URL: https://issues.apache.org/jira/browse/IGNITE-10431
Project: Ignite
Issue Type
, we should validate data on cache
> level. In fact, Ignite already works this way. E.g. nullability checks are
> performed on cache level rather than binary. All we need is to move all
> checks to cache level from binary level.
>
>
> On Thu, Nov 22, 2018 at 9:41 AM Sergi Vladykin
It may be OK to extend compatible field types (like from Int to Long).
In Protobuf for example this is allowed just because there is no difference
between Int and Long in binary format: they all are equally varlen encoded
and Longs just will occupy up to 9 bytes, while Ints up to 5.
But for every
I really like Protobuf format. It is probably not what we need for O(1)
fields access,
but for compact data representation we can derive lots from there.
Also IMO, restricting field type change is absolutely sane idea.
The correct way to evolve schema in common case is to add new fields and
gradua
Sergi Vladykin created IGNITE-10338:
---
Summary: Add Disk page compression test suites to TC
Key: IGNITE-10338
URL: https://issues.apache.org/jira/browse/IGNITE-10338
Project: Ignite
Issue
disk
> page
> > compression.
>
>
> How about setting it at DataRegionConfiguration level as well so that it's
> applied for all the caches/tables from there?
>
>
Does not seem to make much sense until we can tweak page size for different
data regions independently (n
Sergi Vladykin created IGNITE-10332:
---
Summary: Add Ignite.NET configuration for disk page compression
Key: IGNITE-10332
URL: https://issues.apache.org/jira/browse/IGNITE-10332
Project: Ignite
Sergi Vladykin created IGNITE-10331:
---
Summary: Document Disk page compression
Key: IGNITE-10331
URL: https://issues.apache.org/jira/browse/IGNITE-10331
Project: Ignite
Issue Type: New
Sergi Vladykin created IGNITE-10330:
---
Summary: Implement disk page compression
Key: IGNITE-10330
URL: https://issues.apache.org/jira/browse/IGNITE-10330
Project: Ignite
Issue Type
3. In my tests, zstd usually performed much
> better with compression level 2. Please consider.
>
> I admire your effort!
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> пн, 19 нояб. 2018 г. в 14:02, Sergi Vladykin :
>
> > Right now the functionality has nothing to
.
> Is it possible to add compression support for PageSnapshot WAL record as
> well, to reduce WAL size?
>
> Thanks.
>
> On Mon, Nov 19, 2018 at 1:01 PM Sergi Vladykin
> wrote:
>
> > Folks,
> >
> > I've implemented page compression for persistent
Folks,
I've implemented page compression for persistent store and going to merge
it to master.
https://github.com/apache/ignite/pull/5200
Some design notes:
It employs "hole punching" approach, it means that the pages are kept
uncompressed in memory,
but when they get written to disk, they will
I also would like to separate all the automated stuff.
Sergi
пт, 16 нояб. 2018 г. в 13:58, Павлухин Иван :
> Oleg,
>
> I join to Dmitriy. I found your summary quite interesting.
> пт, 16 нояб. 2018 г. в 13:12, Dmitriy Pavlov :
> >
> > Oleg,
> >
> > excellent research! It allows me to avoid bothe
Sven,
Support of materialized views sounds like a huge project. I would not
expect it to appear in Ignite soon.
As far as I see you have problems with data collocation. If you can not
store the original data in replicated caches, then these views will be huge
as well and thus must be partitioned
In SQL indexes we may store partial strings and assume them to be in UTF-8,
I don't think this can be abstracted away. But may be this is not a big
deal if in indexes we still will use UTF-8.
Sergi
2017-07-01 10:13 GMT+03:00 Dmitriy Setrakyan :
> Val, do you know how we compare strings in SQL qu
is required.
> TDE - is one of ways to implement it at the database level.
>
> Sure, an implementation at the application level solve it.
>
> I meant another.
> I thought maybe this feature is in the Ignite roadmap?
>
>
> 2017-06-26 13:53 GMT+03:00 Sergi Vladyk
I think no one is interested in this stuff right now.
Also as far as I see TDE is just an option for PCI DSS compliancy but not a
requirement.
Your system should pass PCI DSS if you will do the required encryption at
the application level and will properly manage encryption keys.
Sergi
2017-06-
+1 to Vladimir. Fields encryption is a user responsibility. I see no reason
to introduce additional complexity to Ignite.
Sergi
2017-06-09 11:11 GMT+03:00 Антон Чураев :
> Seems that Dmitry is referring to transparent data encryption. It is used
> throughout the whale database industry.
>
> 2017
+1
Sergi
2017-06-08 23:03 GMT+03:00 Dmitriy Setrakyan :
> +1 (I will attend)
>
> On Thu, Jun 8, 2017 at 1:02 PM, Konstantin Boudnik wrote:
>
> > That'd be great! Thank you!
> > --
> > Take care,
> > Konstantin (Cos) Boudnik
> > 2CAC 8312 4870 D885 8616 6115 220F 6980 1F27 E622
> >
> > Discla
n-readable type names, how will
> the
> > >> builder approach work? Maybe it makes sense to add an API call that
> > returns
> > >> current type name for a table?
> > >>
> > >> -Val
> > >>
> > >> On Tue, Jun 6, 2017
> wrote:
> >
> > > Vova,
> > >
> > > I am not sure I like the key type name the way it is. Can we add some
> > > separator between the table name and key name, like "_". To me
> > "PERSON_KEY"
> > > reads a lot be
Unique suffix is a good idea.
Sergi
2017-06-06 13:51 GMT+03:00 Vladimir Ozerov :
> Igniters,
>
> In the very first implementation of CREATE TABLE we applied the following
> rule to key and value type names:
> keyTypeName == tableName + "Key"
> valTypeName == tableName
>
> E.g.:
> CREATE TABLE Pe
mode, after that H2 community will add their own hints in another format,
this will look freaky.
Sergi
2017-06-02 17:51 GMT+03:00 Vladimir Ozerov :
> This was exactly what I meant. We need native H2 support here.
>
> On Fri, Jun 2, 2017 at 5:46 PM, Sergi Vladykin
> wrote:
>
> &
IMO the correct way is to implement generic hints for H2 first and plug
Ignite hints there.
Sergi
2017-06-02 17:31 GMT+03:00 Alexey Kuznetsov :
> Hints discussion on H2 user group:
> https://groups.google.com/d/topic/h2-database/dHwbBitzXlY/discussion
>
> On Fri, Jun 2, 2017 at 9:23 PM, Vladimir
I'd prefer to avoid inventing any brand new SQL syntax.
Sergi
2017-06-02 17:23 GMT+03:00 Vladimir Ozerov :
> Well, looks like H2 doesn't support hints at the moment, and there is no
> way to add some custom params to SELECT (it is possible for CREATE TABLE
> and CREATE SCHEMA) only. Anyway, this
If you don't see an exception then it must be supported. This is the whole
point of this exception, right?
Sergi
2017-06-01 22:50 GMT+03:00 Dmitriy Setrakyan :
> On Thu, Jun 1, 2017 at 12:32 PM, Sergi Vladykin
> wrote:
>
> > I guess it must work the following way:
> >
not support it at all and throw an exception.
>
> Is this going to be possible with your solution?
>
> D.
>
> On Thu, Jun 1, 2017 at 2:51 AM, Sergi Vladykin
> wrote:
>
> > The approach you are suggesting will be very complex for current
> > implementation. Also mo
t; Lucene.
> >
> > 2017-05-24 21:56 GMT+03:00 Dmitriy Setrakyan :
> >
> >> Sergi,
> >>
> >> While we are figuring this out, what happens to the GeoSpatial
> >> functionality in the mean time? Is it going to work at all? If not,
> should
>
The approach you are suggesting will be very complex for current
implementation. Also most probably very inefficient.
Actually I was thinking about another but similar approach: in many cases
we can rewrite a subquery in WHERE clause into JOIN subquery.
Like the following:
SELECT x.* FROM x WHER
I think it makes sense to reserve IGNITE schema for future use as well.
2017-06-01 0:26 GMT+03:00 Dmitriy Setrakyan :
> Vladmir,
>
> Thanks for the detailed email. My comments are inline...
>
> On Wed, May 31, 2017 at 11:21 AM, Vladimir Ozerov
> wrote:
>
> > Folks,
> >
> > Let me summarize all r
Done.
Sergi
2017-05-26 21:26 GMT+03:00 Dmitriy Setrakyan :
> On Fri, May 26, 2017 at 8:48 AM, Sergi Vladykin
> wrote:
>
> > Guys,
> >
> > As I see we did not drop AffinityKeyMapper for 2.0.
> >
> > May be lets at least deprecate it?
> >
>
> I think we must. Any objections?
>
PUBLIC is already default schema in H2. You can not even drop it. Oracle
does have PUBLIC schema as well.
Sergi
2017-05-29 16:54 GMT+03:00 Vladimir Ozerov :
> Folks,
>
> I am going to introduce predefined SQL schema which is always accessible on
> all Ignite nodes [1]. Now I am thinking on how t
Guys,
As I see we did not drop AffinityKeyMapper for 2.0.
May be lets at least deprecate it?
Sergi
Guys,
Can someone explain why this strange thingy exists if it does not replace
usual PK tree index?
Sergi
Though this may require some changes in BPlusTree. Let me think.
Sergi
2017-05-24 8:58 GMT+03:00 Sergi Vladykin :
> It must not be too hard to implement kd-tree over b+tree [1]. Depending on
> level we have to compare either X or Y coordinate.
>
> I think we will even have a perfo
Magda :
> +1
>
> This looks natural considering that we switched to the new memory
> architecture. Sergi, how difficult is to support this?
>
> —
> Denis
>
> > On May 23, 2017, at 4:25 AM, Sergi Vladykin
> wrote:
> >
> > Guys,
> >
> > Loo
Guys,
Looks like we have to move our geospatial indexes to the new approach with
BPlusTree. Right now it stores data in Java heap. This is especially
important because we are going to have a persistence layer donated by
GridGain and obviously geo spatial indexes will not work with it at all.
Serg
>
> >> I cannot find a ticket for it. Has it been filed?
> >>
> >> On Fri, May 19, 2017 at 12:38 AM, Vladimir Ozerov >
> >> wrote:
> >>
> >> > Ah, got it. Then I am ok with the change as well.
> >> >
> >> >
Michael,
I see your point. I think it must not be too hard to start asynchronously
establishing connections to all the needed nodes.
I've created respective issue in Jira:
https://issues.apache.org/jira/browse/IGNITE-5277
Sergi
2017-05-23 11:56 GMT+03:00 Michael Griggs :
> Hi Val
>
> This is p
Sergi Vladykin created IGNITE-5277:
--
Summary: Asynchronously establish connection to all the needed
nodes in IgniteH2Indexing.send()
Key: IGNITE-5277
URL: https://issues.apache.org/jira/browse/IGNITE-5277
+1
Sergi
2017-05-23 10:20 GMT+03:00 Valentin Kulichenko <
valentin.kuliche...@gmail.com>:
> +1
>
> On Tue, May 23, 2017 at 8:42 AM, Semyon Boikov
> wrote:
>
> > +1
> >
> > On Tue, May 23, 2017 at 12:55 AM, Denis Magda wrote:
> >
> > > Igniters,
> > >
> > > This branch (https://github.com/apach
rent semantics, and you
> end up with totally confused users on what "type name" means in Ignite.
>
> Let's do not expose strange things to users, and accurately create new
> clean SQL API instead. There is no strong demand for this feature.
>
> On Thu, May 18, 2017
> I agree that this change makes sense.
> > With complex queries it may be non-trivial to get the right column by
> index
> > from results.
> > With metadata user no longer needs to care about result column order, and
> > refactorings are easier.
> >
> >
I believe we will not see this new SQL API soon. It is not even in design
stage.
The change proposed by Andrey is very simple and our users will benefit
from it right away.
I see no reasons to disallow this change.
Sergi
2017-05-18 12:35 GMT+03:00 Vladimir Ozerov :
> Result set metadata is exp
According to our benchmarks Ignite 2.0 is not slower for get operation. I
think we need some minimal reproducer that shows the performance
degradation before making any conclusions.
Sergi
2017-05-12 1:10 GMT+03:00 Yakov Zhdanov :
> Cross-posting to devlist.
>
> --Yakov
>
Sergi Vladykin created IGNITE-5205:
--
Summary: Optimize SQL messaging
Key: IGNITE-5205
URL: https://issues.apache.org/jira/browse/IGNITE-5205
Project: Ignite
Issue Type: Bug
Affects
+1 binding
Sergi
2017-05-02 10:31 GMT+03:00 Alexey Kuznetsov :
> Download zip with sorces: OK
> Build: mvn clean package -DskipTests -Dmaven.javadoc.skip=true: OK
> Build Web console from sources: OK
> Build Web agent from sources: OK
> Start node: OK
> Start Web Console locally: OK
> Start Web
Agree, lets move forward with the simplest possible solution for now.
Sergi
2017-04-25 13:07 GMT+03:00 Vladimir Ozerov :
> Folks,
>
> I do not think it is legal to add such property to ConnectorConfiguration.
> Connector is a generic gateway to cluster resources. It should not bother
> about cac
Looks good to me.
Sergi
2017-04-25 16:53 GMT+03:00 Alexey Goncharuk :
> Igniters,
>
> Since we moved to the PageMemory architecture, several ClusterMetrics
> methods became questionable, so I would like to discuss this before the
> release. Currently, ClusterMetrics contains the following method
It is preferable to avoid hard bindings to some exact scripting engines. If
user wants to plug in Groovy we should allow it.
As for DSL I believe it is a waste of time. Few years ago it was somewhat
popular idea to create DSLs for everything, but no one actually wants to
learn new quirky languages
I'm a bit out of the loop with ML and Web console, but Java scripting
engines as in JSR-233 are supported in Java 7. You can use JSR-233 API in
Web Console, implementation will be in IgniteML module, which requires Java
8 anyways. This way they will be decoupled.
Does this work for you?
Sergi
20
Yes, we need to move on making Ignite work as any usual SQL db.
But please avoid mixing all this stuff together, lets have a separate task
(and discussion if needed) for each item in your list.
Sergi
2017-04-24 16:58 GMT+03:00 Vladimir Ozerov :
> Igniters,
>
> [long read, take a cup of coffee]
I agree with Dmitriy, it is preferable to have this enum registration
optional. It will be a better user experience.
Why do we "inevitably" need it?
Sergi
2017-04-24 17:02 GMT+03:00 Vladimir Ozerov :
> Dima,
>
> No. It is normal (and inevitably) practice to register enums before they
> are used
This ticket is about being able to use enums as INT and VARCHAR literals in
SQL like this:
SELECT name FROM person WHERE job = 'BOSS' or job = 2
Previously you had to always use ? parameters and set enum as a Java object
there, but this is impossible for any usual SQL console. Now we will be
able
Exactly, this syntax was taken from MySQL.
Sergi
2017-04-21 9:58 GMT+03:00 Denis Magda :
> If multiple indexes are listed then H2 will pick only one of them like
> MySql does, right?
>
> Denis
>
> On Thursday, April 20, 2017, Sergi Vladykin
> wrote:
>
> > No
> Alexander P. feel free to assign it on yourself.
> >
> > —
> > Denis
> >
> >> On Jan 23, 2017, at 10:05 AM, Dmitriy Setrakyan
> wrote:
> >>
> >> Very cool! Would be nice to add it to Ignite.
> >>
> >> On Mon, Jan
Guys,
If we have a default of 80% of available memory then just starting few
nodes on my laptop will make it hang. This idea does not work until we have
a dynamically expandable memory pools.
Sergi
2017-04-19 22:20 GMT+03:00 Dmitriy Setrakyan :
> Sergey,
>
> I have responded in the ticket. Can
SQL Queries never instantiate or touch cache entries. Thus SQL queries
never affect any expiration policies.
Sergi
2017-04-19 16:42 GMT+03:00 ALEKSEY KUZNETSOV :
> I wonder if "SELECT" clause should *touch *an entry? For instance,
> cache.contains() doesn't *touch*.
>
> вт, 18 апр. 2017 г. в 12:
Do we have any problems with it? I think if we have some functionality that
require no or little maintenance, then no reason to drop it.
Sergi
2017-04-19 12:28 GMT+03:00 Vladimir Ozerov :
> Folks,
>
> In old pre-Hadoop-accelerator days we implemented map-reduce over native
> IGFS API. See Ignite
Sergi Vladykin created IGNITE-5016:
--
Summary: SQL: Support LEFT JOIN from replicated table to a
partitioned.
Key: IGNITE-5016
URL: https://issues.apache.org/jira/browse/IGNITE-5016
Project: Ignite
Yakov,
The idea of tracking current operations and wait if needed looks
overcomplicated and most probably will result in performance drop.
I think there is no way to have this guarantee with PRIMARY_SYNC in general
case.
Sergi
2017-04-18 13:25 GMT+03:00 Yakov Zhdanov :
> Guys, what if we look
It only means that we will parse the query always and check if it contains
only replicated tables or not. If it does, then we execute the query on a
single node across all the partitions.
Sergi
2017-04-18 12:26 GMT+03:00 Dmitriy Setrakyan :
> On Tue, Apr 18, 2017 at 2:21 AM, Sergi Vlady
nc or async backup updates?
>
> On Tue, Apr 18, 2017 at 1:11 AM, Sergi Vladykin
> wrote:
>
> > Val,
> >
> > There we were not able to run queries against partitioned tables using
> > replicated cache API (I already fixed that in master).
> >
> > Here
<
valentin.kuliche...@gmail.com>:
> Can you please elaborate then? What is the logic there?
>
> -Val
>
> On Tue, Apr 18, 2017 at 9:55 AM, Sergi Vladykin
> wrote:
>
> > Val,
> >
> > That discussion has nothing to do with this PRIMARY_SYNC problem.
>
> >
> > On Tue, Apr 18, 2017 at 10:42 AM, Valentin Kulichenko <
> > valentin.kuliche...@gmail.com> wrote:
> >
> > > This sounds more like an issue with query execution, rather than wrong
> > > PRIMARY_SYNC
> > > behavior. We already had a discussion a
cution, rather than wrong
> PRIMARY_SYNC
> behavior. We already had a discussion about this optimization in replicated
> cache and decided to switch it off by default.
>
> -Val
>
> On Tue, Apr 18, 2017 at 9:35 AM, Sergi Vladykin
> wrote:
>
> > With replicated cache w
With replicated cache we can execute a query against backup partitions that
were not updated yet because of PRIMARY_SYNC. Thus we do not see an update.
Sergi
2017-04-18 10:30 GMT+03:00 Dmitriy Setrakyan :
> Vladimir,
>
> What is wrong with a query in PRIMARY_SYNC mode? Why won't it work?
>
> D.
Nice! Finally Ignite from a "Middleware Solution" becoming an "All In One
Backend Solution".
Sergi
2017-04-18 5:46 GMT+03:00 Dmitriy Setrakyan :
> Great news and I am glad that GridGain was finally able to open source such
> an essential feature to Ignite. Given that I was deeply involved in the
May be drop it in 2.0 then?
Sergi
2017-04-14 19:11 GMT+03:00 Nikita Ivanov :
> As the original developer/author of Scalar (and I already voiced this
> opinion before) - I think we should deprecate Scalar. Ignite APIs can be
> used from Scala as-is with minimal, if any, pimping. The custom DSL
>
That API always was a big mistake. I'm for removing it completely.
Sergi
2017-04-14 18:01 GMT+03:00 Dmitriy Setrakyan :
> What is this obsession with breaking stuff? Let's deprecated it, it is a
> big change on API.
>
> On Fri, Apr 14, 2017 at 7:04 AM, Vladimir Ozerov
> wrote:
>
> > Folks,
> >
configuration(...) function
> to create configuration templates, but how would you associate a
> configuration template with a table inside of "create table" statement?
>
> D.
>
> On Wed, Apr 12, 2017 at 11:22 PM, Sergi Vladykin >
> wrote:
>
> > I do not thi
gt;> Do you mean 2. as the issue? If it’s so then can’t we just detect on
> our
> > >> own that all the caches are replicated and execute a query more
> optimal?
> > >> This should omit necessity to add isReplicatedOnly()?
> > >>
> > >> —
>
Sergi Vladykin created IGNITE-4955:
--
Summary: Correctly execute SQL queries started on replicated cache.
Key: IGNITE-4955
URL: https://issues.apache.org/jira/browse/IGNITE-4955
Project: Ignite
parameters for H2 functions. But this is the right thing
to do here.
Sergi
2017-04-12 23:59 GMT+03:00 Dmitriy Setrakyan :
> Got it. Can we also add CONFIGURATION keyword?
>
> On Wed, Apr 12, 2017 at 11:34 AM, Sergi Vladykin >
> wrote:
>
> > Dmitriy,
> >
> > H2
ysical servers.
>
> D.
>
> On Wed, Apr 12, 2017 at 11:08 AM, Sergi Vladykin >
> wrote:
>
> > Looks like a bug to me.
> >
> > Sergi
> >
> > 2017-04-12 21:03 GMT+03:00 Дмитрий Рябов :
> >
> > > Why not? I do something with cache inside tra
ble to
> support the user-specific syntax.
>
> Sergi, am I missing something?
>
> D.
>
> On Wed, Apr 12, 2017 at 8:51 AM, Sergi Vladykin
> wrote:
>
> > If it is that little, then all this copy/paste shit-coding makes no
> sense.
> >
> > We have to add a
Looks like a bug to me.
Sergi
2017-04-12 21:03 GMT+03:00 Дмитрий Рябов :
> Why not? I do something with cache inside transaction. The only reason to
> not rollback is another node?
>
> 2017-04-12 19:52 GMT+03:00 Andrey Mashenkov :
>
> > Hi Dmitry,
> >
> > Looks like you start transaction on node
7;ll just spend some time in the weekend and come up with a
> prototype as otherwise this talk seems to be just a chit-chat.
>
> - Alex
>
> 2017-04-12 14:38 GMT+03:00 Sergi Vladykin :
> > So basically in inherited class you are going co copy/paste base class
> > methods and tw
and results will be same for isReplicatedOnly flag
> and for isLocal flag turned on?
> If my understanding is correct, we will get same results and there is no
> need to introduce a new flag.
>
>
>
> On Wed, Apr 12, 2017 at 2:54 PM, Sergi Vladykin
> wrote:
>
> >
ng.
>
>
>
>
>
> On Wed, Apr 12, 2017 at 2:36 PM, Sergi Vladykin
> wrote:
>
> > Andrey,
> >
> > Because if you run query on replicated cache, but select data from a
> > partitioned table, you will get only a part of the result.
> >
> > I
would be just inheriting Parser on
> Ignite side and plugging its instance in SINGLE place. Just making H2's
> Parser internal methods protected instead of private would let us do the
> trick.
>
> — Alex
>
> среда, 12 апреля 2017 г. пользователь Sergi Vladykin написал:
>
ds to to wrong results?
> > Is it due to we can read backup entries?
> >
> > On Wed, Apr 12, 2017 at 12:31 PM, Sergi Vladykin <
> sergi.vlady...@gmail.com
> > >
> > wrote:
> >
> > > Guys,
> > >
> > > I want to intro
Sergey,
We've already discussed this and decided to have a cache per table, because
otherwise user will be forced to have unique keys across multiple
independent tables, which is bad.
Thus the idea with TABLESPACE does not really work for us.
Sergi
2017-04-12 13:15 GMT+03:00 Sergi Vla
params. And that's all with respect to
> H2, nothing more.
>
> After that, on Ignite side we do all we want with our parser based on
> theirs. It resembles story with custom types — first we make H2 extendable
> in the way we need, then we introduce exact features we need on Ign
Guys,
I want to introduce another breaking change for 2.0.
Currently SQL is being processed differently when we call method `query` on
partitioned cache and on replicated: on replicated cache we do not do any
extra processing and execute the query as is on current node.
This behavior historicall
ied to QueryEntity in any
> > way,
> > > this violates separation of concerns.
> > >
> > > So I guess we can agree on sorting fields alphabetically.
> > >
> > > Let's get to the initial question:
> > > * Should we do the sorting for the user (p
It definitely makes sense to add a separate mode for Ignite in H2. Though
it is wrong to think that it will allow us to add any crazy syntax we want
(and it is actually a wrong idea imo), only the minor variations of the
existing syntax. But this must be enough.
I believe we should end up with som
t; Sergi
> >
> > 2017-04-10 19:56 GMT+03:00 Vladimir Ozerov :
> >
> > > Guys,
> > >
> > > The problem is that order of fields serialization is unknown for
> regular
> > > objects, where "regular" stands for non-Binarilyzable class.
>
> > I agree that this interface is problematic. However, I don't think that
> > dropping it right away would be fair to our users. Can we deprecate it
> and
> > print out a warning that AffinityKeyMapper cannot be used with DDL
> > statements?
> >
> >
Guys,
We are moving in direction of better distributed SQL support, it means that
we always will need to know an affinity field name for key type.
Now we have AffinityKeyMapper which hides it from us.
Since we have other means of configuring the affinity key, e.g
CacheKeyConfiguration and @Affin
not match
> fields order between class and QueryEntity. This is why we introduced
> sorting, and this is why idea to rely on QueryEntity doesn't work.
>
> On Mon, Apr 10, 2017 at 7:01 PM, Sergi Vladykin
> wrote:
>
> > Why "regular" are different here?
> &g
entities.
>
> 10 апр. 2017 г. 18:52 пользователь "Dmitriy Setrakyan" <
> dsetrak...@apache.org> написал:
>
> On Mon, Apr 10, 2017 at 8:28 AM, Sergi Vladykin
> wrote:
>
> > The decision to use alphabetic order looks strange here. Using order
>
On Mon, Apr 10, 2017 at 8:21 AM, Pavel Tupitsyn
> wrote:
>
> > Sergi, DML writes fields in alphabetic order and computes hash code
> > accordingly.
> > If user-defined Binarylizable impl uses different order, hash codes will
> be
> > inconsistent.
> >
ash code
> accordingly.
> If user-defined Binarylizable impl uses different order, hash codes will be
> inconsistent.
>
> On Mon, Apr 10, 2017 at 6:18 PM, Sergi Vladykin
> wrote:
>
> > What is correct or incorrect ordering for DML?
> >
> > Sergi
> >
provides fields in the wrong order.
>
> D.
>
> On Mon, Apr 10, 2017 at 8:07 AM, Sergi Vladykin
> wrote:
>
> > Could you please elaborate why would we want to sort fields in
> > Binarilyzable
> > classes?
> >
> > If you are taking from stable binary rep
Could you please elaborate why would we want to sort fields in Binarilyzable
classes?
If you are taking from stable binary representation perspective, then I
think it is a problem of user, but not ours.
Sergi
2017-04-10 17:53 GMT+03:00 Vladimir Ozerov :
> Zapalniki,
>
> Inspired by IGNITE-4669
lt
> > all caches from one set will use the same assignment that will be
> > calculated exactly once and will not depend on cache start topology.
> >
> >
> >
> >
> >
> >
> > On Mon, Apr 10, 2017 at 4:05 PM, Sergi Vladykin
> > wrote:
> &g
As for default value for useBalancer flag, I agree with Yakov, it must be
enabled by default. Because performance in steady state is usually more
important than performance of rebalancing. For edge cases it can be
disabled.
Sergi
2017-04-10 15:04 GMT+03:00 Sergi Vladykin :
> If
1 - 100 of 372 matches
Mail list logo