[jira] [Created] (IGNITE-10937) Support data page scan for JDBC/ODBC

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

[jira] [Created] (IGNITE-10798) Data page scan for ScanQuery, SqlQuery and SqlFieldsQuery

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

[jira] [Created] (IGNITE-10431) Make tests independent of memory size

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

Re: [IMPORTANT] Future of Binary Objects

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 > wrote: > > &

Re: [IMPORTANT] Future of Binary Objects

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

Re: [IMPORTANT] Future of Binary Objects

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

[jira] [Created] (IGNITE-10338) Add Disk page compression test suites to TC

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

Re: Disk page compression for Ignite persistent store

> > 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 (now we can't). I woul

[jira] [Created] (IGNITE-10332) Add Ignite.NET configuration for disk page compression

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

[jira] [Created] (IGNITE-10331) Document Disk page compression

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

[jira] [Created] (IGNITE-10330) Implement disk page compression

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

Re: Disk page compression for Ignite persistent store

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

Re: Disk page compression for Ignite persistent store

AL record. > 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 store

Disk page compression for Ignite persistent store

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

Re: Time to remove automated messages from the devlist?

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

Re: Using materialised views for queries with joins

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

Re: Custom string encoding

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

Re: Transparent Data Encryption (TDE) in Apache Ignite

ata" > Encryption 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

Re: Transparent Data Encryption (TDE) in Apache Ignite

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

Re: Data compression in Ignite 2.0

+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

Re: [DISCUSS] Webinar for Ignite Persistent Store walk-through

+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

Re: Key type name and value type name for CREATE TABLE

t; > > >> -Val > > >> > > >> On Tue, Jun 6, 2017 at 7:43 PM Dmitriy Setrakyan < > dsetrak...@apache.org > > > > > >> wrote: > > >> > > >>> Vova, > > >>> > > >>> I am not sure I like

Re: Key type name and value type name for CREATE TABLE

etrakyan <dsetrak...@apache.org> > > 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 > > &

Re: Key type name and value type name for CREATE TABLE

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

Re: Expose SqlQueryFields flags as SQL hints

, 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 <voze...@gridgain.com>: > This was exactly what I meant. We need native H2 support here. > > On Fri, Jun 2, 2017 at 5:46 PM, Sergi Vladyk

Re: Expose SqlQueryFields flags as SQL hints

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,

Re: Expose SqlQueryFields flags as SQL hints

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

Re: nested SQL sub-queries with non-collocated joins

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 <dsetrak...@apache.org>: > On Thu, Jun 1, 2017 at 12:32 PM, Sergi Vladykin <sergi.vlady...@gmail.com> > wrote: > >

Re: nested SQL sub-queries with non-collocated joins

t; it, I would rather 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 <sergi.vlady...@gmail.com> > wrote: > > > The approach you are suggesting will be very c

Re: Geo spatial index

>> functionality in the mean time? Is it going to work at all? If not, > should > >> we throw some sort of exception? > >> > >> D. > >> > >> On Wed, May 24, 2017 at 1:44 AM, Sergi Vladykin < > sergi.vlady...@gmail.com> > >> wrote: >

Re: nested SQL sub-queries with non-collocated joins

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

Re: Summary of SQL changes in 2.1

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 >

Re: AffinityKeyMapper

Done. Sergi 2017-05-26 21:26 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org>: > On Fri, May 26, 2017 at 8:48 AM, Sergi Vladykin <sergi.vlady...@gmail.com> > wrote: > > > Guys, > > > > As I see we did not drop AffinityKeyMapper for 2.0. > > >

Re: Default SQL schema name

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

AffinityKeyMapper

Guys, As I see we did not drop AffinityKeyMapper for 2.0. May be lets at least deprecate it? Sergi

H2PkHashIndex

Guys, Can someone explain why this strange thingy exists if it does not replace usual PK tree index? Sergi

Re: Geo spatial index

Though this may require some changes in BPlusTree. Let me think. Sergi 2017-05-24 8:58 GMT+03:00 Sergi Vladykin <sergi.vlady...@gmail.com>: > 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

Re: Geo spatial index

Magda <dma...@apache.org>: > +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 <sergi.vlady...@gmail.com> > wr

Geo spatial index

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.

Re: SqlFields query result does not expose fields metadata.

...@apache.org> > > wrote: > > > >> I cannot find a ticket for it. Has it been filed? > >> > >> On Fri, May 19, 2017 at 12:38 AM, Vladimir Ozerov <voze...@gridgain.com > > > >> wrote: > >> > >> > Ah, got it. Then I am ok wit

Re: Inefficient approach to executing remote SQL queries

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

[jira] [Created] (IGNITE-5277) Asynchronously establish connection to all the needed nodes in IgniteH2Indexing.send()

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

Re: [VOTE] Accept Contribution of Ignite Persistent Store

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

Re: SqlFields query result does not expose fields metadata.

on/QueryEntity, which have different 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.

Re: SqlFields query result does not expose fields metadata.

itsyn <ptupit...@apache.org> > wrote: > > > 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 >

Re: SqlFields query result does not expose fields metadata.

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

Re: [VOTE] Apache Ignite 2.0.0 RC2

+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

Re: Null cache names

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

Re: Cluster metrics - review for PageMemory

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

Re: Ignite ML, next steps (IGNITE-5029)

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

Re: Ignite ML, DSL/Scripting (IGNITE-5065)

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

Re: SQL usability: catalogs, schemas and tables

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,

Re: Improve binary enum handling

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

Re: SQL: Index hints

Exactly, this syntax was taken from MySQL. Sergi 2017-04-21 9:58 GMT+03:00 Denis Magda <dma...@gridgain.com>: > 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 &

Re: SQL: Index hints

ra/browse/IGNITE-4594> > > > > Alexander P. feel free to assign it on yourself. > > > > — > > Denis > > > >> On Jan 23, 2017, at 10:05 AM, Dmitriy Setrakyan <dsetrak...@apache.org> > wrote: > >> > >> Very cool! Would be n

Re: Page Memory behavior with default memory policy

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

Re: TouchedExpiryPolicy works incorrect in some cases IGNITE-4401

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

Re: Remove IGFS map-reduce in 2.0

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

[jira] [Created] (IGNITE-5016) SQL: Support LEFT JOIN from replicated table to a partitioned.

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

Re: Performance vs correctness: I vote fore the second

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

Re: Performance vs correctness: I vote fore the second

7 at 2:21 AM, Sergi Vladykin <sergi.vlady...@gmail.com> > wrote: > > > We never read from backups on partitioned cache, but for replicated we do > > that to be able to execute the whole query on single node locally.\ > > > > But I thought that we agreed to change t

Re: Performance vs correctness: I vote fore the second

o we care > about sync or async backup updates? > > On Tue, Apr 18, 2017 at 1:11 AM, Sergi Vladykin <sergi.vlady...@gmail.com> > wrote: > > > Val, > > > > There we were not able to run queries against partitioned tables using > > replicated cache API (I alre

Re: Performance vs correctness: I vote fore the second

< 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 <sergi.vlady...@gmail.com> > wrote: > > > Val, > > > > That discussion has nothing to do with th

Re: Performance vs correctness: I vote fore the second

y 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 < > > sergi.vlady...@gmail.com> &g

Re: Performance vs correctness: I vote fore the second

n, 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 <sergi.vlady...@gmail.com> > wrote: > > &

Re: Performance vs correctness: I vote fore the second

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?

Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)

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

Re: Discontinue Scalar in Ignite-2.0?

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,

Re: Remove or deprecate IgniteAsyncSupport?

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

Re: CREATE TABLE SQL command syntax

> work with tables. I can see a use for a table_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 &

[jira] [Created] (IGNITE-4955) Correctly execute SQL queries started on replicated cache.

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

Re: CREATE TABLE SQL command syntax

parameters for H2 functions. But this is the right thing to do here. Sergi 2017-04-12 23:59 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org>: > Got it. Can we also add CONFIGURATION keyword? > > On Wed, Apr 12, 2017 at 11:34 AM, Sergi Vladykin <sergi.vlady...@gma

Re: Question about cache and transaction on different nodes

would be on different physical servers. > > D. > > On Wed, Apr 12, 2017 at 11:08 AM, Sergi Vladykin <sergi.vlady...@gmail.com > > > wrote: > > > Looks like a bug to me. > > > > Sergi > > > > 2017-04-12 21:03 GMT+03:00 Дмитрий Рябов <somef

Re: Question about cache and transaction on different nodes

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

Re: CREATE TABLE SQL command syntax

nd 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 <sergi.vlady...@gmail.com>: > > So basically in inherited class you are going co copy/paste base class > > methods a

Re: SQL on PARTITIONED vs REPLICATED cache

> > Does query execution way 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 &l

Re: SQL on PARTITIONED vs REPLICATED cache

eagalStateException with no message is confusing. > > > > > > On Wed, Apr 12, 2017 at 2:36 PM, Sergi Vladykin <sergi.vlady...@gmail.com> > wrote: > > > Andrey, > > > > Because if you run query on replicated cache, but select data from a > > partitioned ta

Re: CREATE TABLE SQL command syntax

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 написал: > > > I don

Re: SQL on PARTITIONED vs REPLICATED cache

to replicated cache leads 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

Re: CREATE TABLE SQL command syntax

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 Vladykin

Re: CREATE TABLE SQL command syntax

h 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 Ignite > side. > > — Ale

SQL on PARTITIONED vs REPLICATED cache

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

Re: Sorting fields of Binarilyzable objects on write

et's get to the initial question: > > > * Should we do the sorting for the user (performance hit)? > > > * Should we at least validate user-defined order? > > > > > > On Wed, Apr 12, 2017 at 2:12 AM, Dmitriy Setrakyan < > > dsetrak...@apache.org> > > &

Re: CREATE TABLE SQL command syntax

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

Re: Sorting fields of Binarilyzable objects on write

; > On Mon, Apr 10, 2017 at 10:43 AM, Sergi Vladykin <sergi.vlady...@gmail.com > > > wrote: > > > I'm sorry, looks like I do not really well understand this stuff, but it > is > > still not clear to me why wouldn't we just take the order of key fields > > give

Re: AffinityKeyMapper: break compatibility before 2.0

<dsetrak...@apache.org > > > wrote: > > > 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 w

AffinityKeyMapper: break compatibility before 2.0

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

Re: Sorting fields of Binarilyzable objects on write

his reason you cannot 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 <sergi.vlady...@gmail.com> > wrote: > > > Why "regular&q

Re: Sorting fields of Binarilyzable objects on write

participate in multiple query entities. > > 10 апр. 2017 г. 18:52 пользователь "Dmitriy Setrakyan" < > dsetrak...@apache.org> написал: > > On Mon, Apr 10, 2017 at 8:28 AM, Sergi Vladykin <sergi.vlady...@gmail.com> > wrote: > > > The decision to use a

Re: Sorting fields of Binarilyzable objects on write

codes will > be > > inconsistent. > > > > On Mon, Apr 10, 2017 at 6:18 PM, Sergi Vladykin < > sergi.vlady...@gmail.com> > > wrote: > > > > > What is correct or incorrect ordering for DML? > > > > > > Sergi > > > >

Re: Sorting fields of Binarilyzable objects on write

lphabetic order and computes hash 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 <sergi.vlady...@gmail.com> > wrote: > > > What is correct or

Re: Sorting fields of Binarilyzable objects on write

throw exception if user somehow provides fields in the wrong order. > > D. > > On Mon, Apr 10, 2017 at 8:07 AM, Sergi Vladykin <sergi.vlady...@gmail.com> > wrote: > > > Could you please elaborate why would we want to sort fields in > > Binarilyzable > &

Re: Sorting fields of Binarilyzable objects on write

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

Re: Prohibit stateful affinity (FairAffinityFunction)

the same affinity for some cache set. As result > > 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,

Re: Prohibit stateful affinity (FairAffinityFunction)

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 <sergi.vl

Re: Prohibit stateful affinity (FairAffinityFunction)

: > > > We should have it enabled by default. > > > > --Yakov > > > > 2017-04-10 12:42 GMT+03:00 Sergi Vladykin <sergi.vlady...@gmail.com>: > > > > > Why wouldn't we have useBalancer always enabled? > > > > > > Sergi > > > > >

Re: Prohibit stateful affinity (FairAffinityFunction)

on? >> >> Generally I agree. If FairAffinityFunction can't be changed to provide >> consistent mapping, it should be dropped. >> >> -Val >> >> On Sun, Apr 9, 2017 at 3:50 AM, Sergi Vladykin <sergi.vlady...@gmail.com >> <mailto:sergi.vlady...@gmail.co

null Cache names

Who can pickup this one? We should do it before 2.0 https://issues.apache.org/jira/browse/IGNITE-3488 Sergi

Re: IGNITE-4878 ready for review

Michael, This code is already changed in my branch for lazy SQL, so I will not merge your PR. Thanks for pointing out the issue anyways! Sergi 2017-04-07 20:00 GMT+03:00 michael.griggs : > This change is https://issues.apache.org/jira/browse/IGNITE-4878 > >

Re: Stable binary key representation

gt; -- > Denis > > On Sun, Apr 9, 2017 at 6:54 AM, Sergi Vladykin <sergi.vlady...@gmail.com> > wrote: > > > Ok, we need to do 2 things here: > > > > 1. Drop the resolvers from the source code. > > 2. Write a good page in docs on "What makes a correc

  1   2   3   4   >