Re: Global off-heap memory limit

That is true, in Ignite 2.0 you will be able to setup one or more differently configured memory pools per node. When you start a cache you have to decide which one to use for this cache. The caches attached to the same pool together will not be able to grow beyond the maximum size of that pool. Se

Re: Custom aggregate function in H2 SQL

It depends on what exactly do you want. You can post your thoughts here first for discussion. Of course we will not accept "simple patch", we need a universal approach that will work not only on local node but for distributed SQL queries as well. Sergi 2016-09-15 5:57 GMT+03:00 sibnick : > I nee

[jira] [Created] (IGNITE-3860) Improve distributed SQL support.

Sergi Vladykin created IGNITE-3860: -- Summary: Improve distributed SQL support. Key: IGNITE-3860 URL: https://issues.apache.org/jira/browse/IGNITE-3860 Project: Ignite Issue Type: Bug

Re: Request for assign to ticket.

I've added you to contributors list in Jira, feel free to assign the issue to yourself. Sergi 2016-08-26 13:42 GMT+03:00 Eduard Yuzlikeev : > Hi > I want to work on next bug > https://issues.apache.org/jira/browse/IGNITE-2092?jql= > project%20%3D%20IGNITE%20AND%20labels%20in%20%28newbie%29% > 20

Re: Contributing to Apache Ignite

Hi John! It's great to see you in Apache Ignite community! I've added you to contributors list on Jira. Sergi 2016-08-22 17:06 GMT+03:00 John Levey : > Hi List, > > My name is John Levey and I am a software developer at Workday, and > colleague of Patrick Peralta (a recent contributor to this A

Re: Ignite Maven project version number

I'm not a Maven expert and do not see all the consequences, but so far everything worked well. Why change it? Especially if we do not have a consensus in our community. I think we can't accept this change until everyone agrees. Sergi 2016-08-19 10:28 GMT+03:00 Anton Vinogradov : > Igor, > > > >

[jira] [Created] (IGNITE-3685) H2 Debug console does not show list of tables.

Sergi Vladykin created IGNITE-3685: -- Summary: H2 Debug console does not show list of tables. Key: IGNITE-3685 URL: https://issues.apache.org/jira/browse/IGNITE-3685 Project: Ignite Issue

Re: Ignite 2.0 tasks/roadmap

I'm aware of this issue. My plan was to allow setting the same schema name to different caches using CacheConfiguration.setSqlSchema(...). This way we will have separate caches but from SQL point of view respective tables will reside in the same schema. No need to introduce new concepts. Sergi 2

Re: .Net's QueryExample mixes everything in a single cache

Yes, it is a good idea, because I think in 2.0 we will disallow having more than a single type in a cache. Sergi 2016-08-10 9:35 GMT+03:00 Vladimir Ozerov : > I do not know the reason. Let's split. > > On Wed, Aug 10, 2016 at 9:05 AM, Pavel Tupitsyn > wrote: > > > Hi Denis, > > > > It has alway

Re: All BinaryObjects created by BinaryObjectBuilder stored at the same partition by default

likely to have problems with normal GETs/PUTs. > > 5) Add another implementation which will use encoded string to calculate > a > > hash code. E.g. *new BinaryEqualsHashCodeResolver("{a} * 31 + {b}")*. > > Originally proposed by Yakov some time ago. > > &g

Re: All BinaryObjects created by BinaryObjectBuilder stored at the same partition by default

will be automatically > > generated, if not provided. > > > > This is as clean as it will ever get. > > > > Thoughts? > > > > D. > > > > > > On Sat, Aug 6, 2016 at 1:25 AM, Sergi Vladykin > > > wrote: > > > > > Keep i

Re: All BinaryObjects created by BinaryObjectBuilder stored at the same partition by default

Keep in mind that we need to support affinity keys in BinaryObjects. It means that it will have to consist from at least two fields: one for exact equality check and another one for hashCode calculation. It looks to me that configuration of cache key is a part of cache configuration. Thus cache ke

Re: IGNITE-2294 implementation details

sultSet makes sense only for SqlFieldsQuery only in Jdbc. > Thanks, will fix it. > > - Alex > > 2016-08-04 9:43 GMT+03:00 Sergi Vladykin : > > About new public APIs 2. > > > > QueryCursor.isResultSet makes sense only for SqlFieldsQuery only in Jdbc. > > Thus

Re: IGNITE-2294 implementation details

About new public APIs 2. QueryCursor.isResultSet makes sense only for SqlFieldsQuery only in Jdbc. Thus it must be private on QueryCursorEx like fieldsMeta() for example. All in all, there should be no changes on public API at this point. Sergi 2016-08-04 9:05 GMT+03:00 Sergi Vladykin

Re: IGNITE-2294 implementation details

Also about new public APIs. I don't see why we need SqlFieldsQuery.isQuery, looks like it has to be optional, so it will only confuse users. Sergi 2016-08-04 9:00 GMT+03:00 Sergi Vladykin : > Why do we need to count query arguments? Can anyone clarify? > > Sergi > > 2016-

Re: IGNITE-2294 implementation details

Why do we need to count query arguments? Can anyone clarify? Sergi 2016-08-04 5:07 GMT+03:00 Alexey Kuznetsov : > About arguments number. I see following options here: > 1. Somehow use H2 engine to parse SQL string and check results. > 2. Use some other parsing library instead of H2 but this wi

Re: [VOTE] Apache Ignite 1.7.0 RC1

+1 binding Sergi 2016-08-03 15:04 GMT+03:00 Nikolai Tikhonov : > +1 (binding) > > On Wed, Aug 3, 2016 at 1:25 PM, Vladimir Ozerov > wrote: > > > +1 (binding) > > > > Looks good to me. > > > > On Wed, Aug 3, 2016 at 10:48 AM, Alexey Kuznetsov < > akuznet...@gridgain.com > > > > > wrote: > > > >

Re: IGNITE-2294 implementation details

version of current API changes - it's quite modest > https://goo.gl/Y6Cv1b > > - Alex > > 2016-07-28 20:34 GMT+03:00 Alexander Paschenko > : > > Sergi, > > > > OK, I've done it as you said, thanks. > > Now working on binary marshaller support. &g

Re: JetBrains Annotaions usage.

I don't think that JB annotations is a runtime dependency, we should need them only at compile time, no? Sergi 2016-07-28 11:09 GMT+03:00 Anton Vinogradov : > Igniters, > > As you may know we had only 2 dependencies at ignite-core: jcache and > ignite-shmen. > > IGNITE-3323 Get rid of copypasted

Re: Enums and SQL queries

No, as I told you, we have to contribute this feature to H2. Sergi 2016-07-28 10:23 GMT+03:00 Dmitriy Setrakyan : > Sergi, is there a standard way to add a custom type to H2? Is it > documented? > > On Thu, Jul 28, 2016 at 2:17 AM, Sergi Vladykin > wrote: > >

Re: Enums and SQL queries

Sure. https://issues.apache.org/jira/browse/IGNITE-3595 Sergi 2016-07-27 22:51 GMT+03:00 Dmitriy Setrakyan : > Sorry, Sergi. What I meant is to file a ticket with the design you > suggested > > Dmitriy > > > > > On Jul 27, 2016, at 9:18 AM, Sergi Vladykin > wrote

[jira] [Created] (IGNITE-3595) Improve Enum fields handling in SQL.

Sergi Vladykin created IGNITE-3595: -- Summary: Improve Enum fields handling in SQL. Key: IGNITE-3595 URL: https://issues.apache.org/jira/browse/IGNITE-3595 Project: Ignite Issue Type

Re: IGNITE-2294 implementation details

ank you very much for giving them. Please refer to > PR to see current state of the work. > Will surely look into ODBC, .NET and Visor. Though they will most > likely have to support a new feature rather than considerably change > existing logic. > > - Alex > > 2016-07-27 14:2

Re: Enums and SQL queries

the > query result. However, this is not a clean solution, I agree, but could be > a quick one. > > I don't mind breaking compatibility on this issue, given that it never > worked properly anyway. Can you please file a ticket? > > D. > > On Wed, Jul 27, 2016 at 3

Re: IGNITE-2294 implementation details

FieldsQuery is used in JDBC driver. Thanks. > > - Alex > > 2016-07-27 13:02 GMT+03:00 Sergi Vladykin : > > Where did you see R in SqlFieldsQuery? > > > > Sergi > > > > 2016-07-27 12:59 GMT+03:00 Alexander Paschenko < > > alexander.a.pasche...@gmai

Re: IGNITE-2294 implementation details

>> > >> You wrote: > >> > What is the ticket number for this. Is the new API documented there? > >> > >> Overall issue number is 2294. There's no particular issue on API > >> changes, but creating one seems to be a good idea, I will do i

Re: IGNITE-2294 implementation details

seems to be a good idea, I will do it. > > - Alex > > 2016-07-27 9:20 GMT+03:00 Dmitriy Setrakyan : > > What is the ticket number for this. Is the new API documented there? > > > > On Tue, Jul 26, 2016 at 11:36 AM, Sergi Vladykin < > sergi.vlady...@gmail.com>

Re: Data compression in Ignite 2.0

Nikita, I agree with Andrey, HANA is a bad comparison to Ignite in this respect. I did not find any evidence on the internet that their row store is very efficient with compression. It was always about column store. Alexey, As for DB2, can you check what exactly, when and how it compresses and d

Re: Enums and SQL queries

. > > In case if user expects a String, can we catch an exception and do > automatic conversion at that time? In this case, we could catch the > exception once and remember the decision. Will something like this work? > > D. > > On Tue, Jul 26, 2016 at 1:49 AM, Sergi Vladyk

Re: IGNITE-2294 implementation details

ys returning an empty iterator > for any non-select query, it seems ugly design wise. > > - Alex > > 2016-07-26 18:15 GMT+03:00 Sergi Vladykin : > > BTW, the simplest way to solve this issue is to allow running SQL > commands > > inside of SqlFieldsQuery. > > > >

Re: IGNITE-2294 implementation details

etArgs(1,2)); This will resolve any ambiguity. Sergi 2016-07-26 17:56 GMT+03:00 Sergi Vladykin : > I don't like any pre-parsing, especially with some libraries other than > H2. H2 itself has enough quirks to multiply it on quirks of another library. > > This is exactly what I was t

Re: IGNITE-2294 implementation details

> - MERGE is translated into *put()* call in Ignite > > - For SQL BATCH calls we should delegate to Ignite batch operations, e.g. > > *putAll()* > > > > The above should hold true for atomic and transactional put/putAll calls, > > as well as for the data streame

Re: Enums and SQL queries

w how to use it. Is this > possible? > > -Val > > On Fri, Jul 22, 2016 at 10:25 PM, Sergi Vladykin > wrote: > >> I'm not sure what exactly you are going to patch in SQL engine. We could >> and some SQL function like enum('MY_ENUM_NAME') but probably

Re: Distributed joins for JDBC

sponding ticket created IGNITE-3563 ( > https://issues.apache.org/jira/browse/IGNITE-3563 ). > > On Mon, Jul 25, 2016 at 10:04 AM, Sergi Vladykin > > wrote: > > > I don't think it makes sense to extend JDBC this way because usually if > one > > have access to

Re: Data compression in Ignite 2.0

This will make sense only for rare cases when you have very large objects stored, which can be effectively compressed. And even then it will introduce slowdown on all the operations, which often will not be acceptable. I guess only few users will find this feature useful, thus I think it does not w

Re: Distributed joins for JDBC

BTW this approach will be applicable to ODBC as well as far as I understand, so it will be consistent. Sergi 2016-07-25 10:04 GMT+03:00 Sergi Vladykin : > I don't think it makes sense to extend JDBC this way because usually if > one have access to Java API he most probably will use

Re: Distributed joins for JDBC

I don't think it makes sense to extend JDBC this way because usually if one have access to Java API he most probably will use Ignite API. If for some reason they use JDBC it means that it is an application which was aimed to work with any RDBMS and should not know about quirks of some particular dr

[jira] [Created] (IGNITE-3560) Unify type descriptor removal and destruction in IgniteH2Indexing

Sergi Vladykin created IGNITE-3560: -- Summary: Unify type descriptor removal and destruction in IgniteH2Indexing Key: IGNITE-3560 URL: https://issues.apache.org/jira/browse/IGNITE-3560 Project

Re: Enums and SQL queries

I'm not sure what exactly you are going to patch in SQL engine. We could and some SQL function like enum('MY_ENUM_NAME') but probably it will not work if we will not pass enum type there as well, so it have look like enum('com.mycompany.MyEnum', 'MY_ENUM_NAME') which is ugly. Sergi On 23 июля 201

Re: IGNITE-2294 implementation details

I think these problems we need to solve regardless of DDL. Sergi On 21 июля 2016 г., 16:40, Alexey Goncharuk wrote: > Suppose I have a PersonKey {int id;} class and Person {@SqlQueryField int > id; @SqlQueryField String name; @SqlQueryField int age;} class. > > How would an insert statement loo

Re: IGNITE-2294 implementation details

either Key or Value, this confuses > me a lot. > > Maybe we should come up with DDL first? > > 2016-07-21 14:06 GMT+03:00 Sergi Vladykin : > > > No, this does not make sense. > > > > There is no upsert mode in databases. There are operations: INSERT, > UPDATE, >

Re: IGNITE-2294 implementation details

> > D. > > On Wed, Jul 20, 2016 at 9:39 PM, Sergi Vladykin > wrote: > > > I'd prefer to do MERGE operation last because in H2 it is not standard > ANSI > > SQL MERGE. Or may be not implement it at all, or may be contribute ANSI > > correct version to H2, the

Re: Rework "withAsync" in Apache 2.0

n cache API. > > > > Vladimir. > > > > > > On Thu, Jul 21, 2016 at 12:21 PM, Dmitriy Setrakyan < > dsetrak...@apache.org > > > wrote: > > > >> Do I understand correctly that the community is proposing to have 2 > >> identical interfac

Re: Rework "withAsync" in Apache 2.0

+1 Finally it is time to drop this "cool feature" from Ignite! Sergi On Thu, Jul 21, 2016 at 11:13 AM, Vladimir Ozerov wrote: > Alex. > > Of course, some distributed operations will involve some kind of asynchrony > even in synchronous mode. My point is that we should not blindly do things > l

Re: IGNITE-2294 implementation details

lity) > >> - query() method in IgniteCache (one that accepts Query) and query() > >> methods in GridQueryIndexing return iterators. So, if we strive to > >> leave interfaces unchanged, we still will introduce some design > >> ugliness like query methods return

Re: Ignite 2.0 tasks/roadmap

.com> > wrote: > > > Sergi, that was my idea to drop nulls but I have limited access to > internet > > (I'm on vacation) could you create issue in JIRA? > > > > Thanks. > > > > Alexey Kuznetsov > > > > 15 Июл 2016 г. 15:17 пользователь &qu

[jira] [Created] (IGNITE-3488) Prohibit null as name in all the components (cache name first of all).

Sergi Vladykin created IGNITE-3488: -- Summary: Prohibit null as name in all the components (cache name first of all). Key: IGNITE-3488 URL: https://issues.apache.org/jira/browse/IGNITE-3488 Project

Re: Ignite 2.0 tasks/roadmap

Huge +1 for dropping support for null in all names, not only for cache names. Do we have ticket for this one? Sergi On Fri, Jul 15, 2016 at 2:00 PM, Andrey Velichko wrote: > > 15.07.2016 0:31, Dmitriy Setrakyan пишет: > >> On Fri, Jul 15, 2016 at 12:26 AM, AndreyVel wrote: >> >> Good feature m

Re: Apache Ignite - New Release

> > Is it possible to fix this on SQL engine level instead of fixing only for > JDBC? Sergi, what do you think? > > -Val > > On Thu, Jul 14, 2016 at 3:28 AM, Sergi Vladykin > wrote: > > > All these issues seem to be related to Jdbc driver rather than to SQL > > eng

[jira] [Created] (IGNITE-3482) Implement lazy query execution in H2.

Sergi Vladykin created IGNITE-3482: -- Summary: Implement lazy query execution in H2. Key: IGNITE-3482 URL: https://issues.apache.org/jira/browse/IGNITE-3482 Project: Ignite Issue Type

[jira] [Created] (IGNITE-3481) Implement lazy query execution in H2.

Sergi Vladykin created IGNITE-3481: -- Summary: Implement lazy query execution in H2. Key: IGNITE-3481 URL: https://issues.apache.org/jira/browse/IGNITE-3481 Project: Ignite Issue Type

Re: Apache Ignite - New Release

All these issues seem to be related to Jdbc driver rather than to SQL engine. I think Andrey Gura was the last who worked on it. IMO they must be easy to fix. Sergi On Thu, Jul 14, 2016 at 9:06 AM, Denis Magda wrote: > Yakov, > > I'm not the one who is eligible for review of IGNITE-3389. Assign

Re: Cache performance for LOCAL mode + setIndexedTypes

I guess updating indexes is not free. Sergi On Mon, Jul 11, 2016 at 11:48 PM, AndreyVel wrote: > Hello, I have created simple test for testing performance put operations > on single computer, > can anybody explain why performance for LOCAL mode different for Indexed > and non Indexed mode? > >

Re: Apache Ignite - New Release

Yakov, Good idea. Alexey, Why not just bump it to 1.7 as we do usually? Sergi On Mon, Jul 11, 2016 at 9:21 PM, Alexey Goncharuk < alexey.goncha...@gmail.com> wrote: > There were also numerous contributions merged with small API improvements. > +1 for making a new release. > > Since the chan

Re: Let's make cache name not null in ignite 2.0

+100500 for dropping it. Having null names is the worst idea I can imagine. People will have configuration incompatibilities anyways, disallowing nulls is not a big deal here. Sergi 2016-06-02 3:50 GMT+03:00 Dmitriy Setrakyan : > Warning is OK, but removing null name after having it for almos

[jira] [Created] (IGNITE-3180) Support STDDEV_POP and STDDEV_SAMP aggregate functions over partitioned caches.

Sergi Vladykin created IGNITE-3180: -- Summary: Support STDDEV_POP and STDDEV_SAMP aggregate functions over partitioned caches. Key: IGNITE-3180 URL: https://issues.apache.org/jira/browse/IGNITE-3180

Re: [VOTE] Apache Ignite 1.6.0 RC1

+1 The first time I've ran the build I've got OOM on PremGen. The second attempt was ok. Also I noticed a couple of exceptions in build process, but it finished successfully. I don't think these issues are critical, but it would be nice to fix them for the next release. Sergi 2016-05-19 15:59 GM

[jira] [Created] (IGNITE-3171) Support column selectivity calculation for SQL

Sergi Vladykin created IGNITE-3171: -- Summary: Support column selectivity calculation for SQL Key: IGNITE-3171 URL: https://issues.apache.org/jira/browse/IGNITE-3171 Project: Ignite Issue

Re: SQL statements monitoring and statistics.

3:39 GMT+03:00 Alexey Kuznetsov : > I'm going to implement support for SQL statements monitoring and statistics > in Web Console. > > For this feature we need API that will allow to collect info about what > statements were executed in cluster and their metrics. > > @Sergi

Re: Possible optimizations for SQL + Off-heap

03:00 Denis Magda : > Sergi, > > However if we implement non snapshotable data structure to hold indexes > (skip list or b-tree) then it will be feasible to optimize point 1) - > working with off-heap data with BinaryObjectOffHeapImpl. Am I right? > > — > Denis > >

Re: Possible optimizations for SQL + Off-heap

1. In general it is not possible to keep BinaryObject in "attached" state, because at the query end we release snapshots and the entry can be concurrently removed with offheap memory deallocation, while result row is still needed. 2. Of course there are multiple alternatives (skiplist or b+tree),

[jira] [Created] (IGNITE-3013) Support sorted merge index for SQL

Sergi Vladykin created IGNITE-3013: -- Summary: Support sorted merge index for SQL Key: IGNITE-3013 URL: https://issues.apache.org/jira/browse/IGNITE-3013 Project: Ignite Issue Type

Re: Deprecate GridFunc

+1 I think it is a good idea to mark GridFunc and F with @Depricated annotation and encourage developers to refactor the code which uses them when they come across it. This way we'll gradually get rid of this "true functional programming" stuff. Sergi 2016-04-01 12:46 GMT+03:00 Vladimir Ozerov :

[jira] [Created] (IGNITE-2913) SQL query with EXISTS() expression fails on partitioned cache.

Sergi Vladykin created IGNITE-2913: -- Summary: SQL query with EXISTS() expression fails on partitioned cache. Key: IGNITE-2913 URL: https://issues.apache.org/jira/browse/IGNITE-2913 Project: Ignite

Re: Switching back to review-then-commit process

just it whenever is needed. > > If you have any thoughts, concerns let's discuss them there. > > -- > Denis > > On 3/10/2016 1:37 PM, Sergi Vladykin wrote: > >> If everyone is ok with the proposals, then we need to set this new >> approach >> and p

Re: IGNITE-2708

Sorry, sent email before the thread was updated :) Sergi 2016-03-11 8:11 GMT+03:00 Sergi Vladykin : > Ryan, > > Please provide your login in Jira and we will add you to the list of > contributors, then you should be able to assign it to yourself. > > Sergi > > 2016-03

Re: IGNITE-2708

Ryan, Please provide your login in Jira and we will add you to the list of contributors, then you should be able to assign it to yourself. Sergi 2016-03-10 16:18 GMT+03:00 Ryan Zhao : > Hi guys, > > As a freshman, I am working on IGNITE-2708 >

Re: Switching back to review-then-commit process

If everyone is ok with the proposals, then we need to set this new approach and properly document it. Also we need to select list of RTC modules and elect their maintainers. Sergi 2016-03-05 19:31 GMT+03:00 Sergi Vladykin : > +1 to the original proposal of Denis to introduce module maintain

Re: Hello

Hi Ryan! You can take a look at [1] to get instructions on how start contributing and get a list of "newbie" jira tickets. Should you have any questions, feel free to ask here! 1. http://ignite.apache.org/community/contribute.html#contribute Sergi 2016-03-10 11:31 GMT+03:00 Ryan Zhao : > Hi e

Re: Switching back to review-then-commit process

+1 to the original proposal of Denis to introduce module maintainers and RTC process +1 to the proposal of Raul to restrict number of core modules, which require maintainers review Sergi 2016-03-05 6:43 GMT+03:00 Konstantin Boudnik : > It saddens me to see this coming to it ;( > > On Thu, Mar 0

Re: Creating client caches if 'schema not found' exception is thrown

Val, I didn't look at the code but I hope you've covered case when schema name is configured to be different from the cache name? Sergi 2016-02-27 2:34 GMT+03:00 Alexey Goncharuk : > Looks good to me. >

Re: ODBC processor default behaviour

I think both approaches are ok if the odbc client understands how should it deal with connection failures (should it go through a port range or retry a single port during the period of time). Sergi 2016-02-23 4:35 GMT+03:00 Valentin Kulichenko : > I think the behavior of OdbcProcessor should be

Re: Unfriendly "SELECT *"

Use SqlFieldsQuery, Luke! I tried, it works! :) I was always against SELECT in SqlQuery, it was terrible design decision, but for "historical reasons" it is supported in SqlQuery. As for adding new parsing, the more fancier parsing we will introduce, the worse performance we will have. Sergi 20

Re: 'Date' and 'Timestamp' types in SQL queries

This is because there is no java.util.Date in SQL, we have to either treat it as BLOB or as native SQL type Timestamp. We've chosen the latter approach. Sergi 2016-02-11 18:24 GMT+03:00 Igor Sapego : > Sorry, I meant In our Binary marshaler we use *java.util.Date.* > > Best Regards, > Igor > > O

Re: Transformers in SCAN queries

formers can > be applied to any type of query (including SqlFieldsQuery, I believe). > > On Thu, Feb 4, 2016 at 7:42 PM, Sergi Vladykin > wrote: > > > I don't like the idea of having additional method *query(Query qry, > > Transformer transfomer); *because I don&

Re: Transformers in SCAN queries

I don't like the idea of having additional method *query(Query qry, Transformer transfomer); *because I don't see how these transformers will work for example with SQL, but this API makes you think that transformers are supported for all the query types. Sergi 2016-02-04 16:46 GMT+03:00 Andrey Gu

Re: Adding tracing component to Ignite

+1 I think it is a great idea, still it must be carefully designed to avoid additional performance penalty. BTW, for performance measurements there is already a good component: https://github.com/HdrHistogram/HdrHistogram Sergi 2016-01-30 3:01 GMT+03:00 Dmitriy Setrakyan : > How do you disable

Re: Ignite SQL syntax: key fields, scalars, nested fields

ot;cache".QUERYPERSON._KEY __C0, > "cache".QUERYPERSON._VAL __C1 FROM "cache".QUERYPERSON WHERE _KEY > ?1 > [90027-175] > Looks like a bug to me. Could you open Jira issue with simple reproducible test? Sergi > > > > On Mon, Jan 25, 2016 at 6:38 PM, Serg

Re: Ignite SQL syntax: key fields, scalars, nested fields

- Yes, in SQL it is possible to query cache key and value using aliases _key and _val respectively. - Aggregate functions like SUM, AVG, MIN, MAX are supported. - Nested fields are supported and they are flattened, so name collisions are prohibited. Sergi 2016-01-25 15:26 GMT+03:00 Pavel Tupitsyn

Re: LINQ support in Ignite.NET via re-linq library

Looks cool to me. Sergi 2016-01-22 18:04 GMT+03:00 Pavel Tupitsyn : > Igniters, > > I'm working on LINQ support in Ignite.NET ([1]). > > For the uninitiated, LINQ will allow cache SQL queries in a strongly-typed > way, which is awesome: > cache.ToQueryable().Where(person => person.Age > 20) >

Re: supporting collection indexes

Based on my previous experience this is not something that I have seen > extensively but definitely something that comes up. > > Or am I missing the point completely here? > > Regarding indexing of map values, I’m not exactly sure why you would need > that and I do feel that woul

Re: supporting collection indexes

ects to index act as cache value? > > From my standpoint it will be pretty complex to implement this in a > seamless manner without limitations of any kind. > > --Yakov > > 2016-01-21 20:27 GMT+03:00 Sergi Vladykin : > > > I think this feature can be implemented. > >

Re: supporting collection indexes

I think this feature can be implemented. As far as I understand user will not need to clone the collection or do anything else from what he does now. We well have to drop all the collection items from that separate table and add them again on update. Of course we can try to apply some heuristics l

Re: IgniteBinary, POJOs and indexing

As for dynamic caches this is usually ok, because application can use method getOrCreateCache(). For dynamic indexes probably you don't want to write all the initialization logic each time client tries to access cache. Sergi 2016-01-11 14:07 GMT+03:00 Sergi Vladykin : > I mean it would

Re: IgniteBinary, POJOs and indexing

I mean it would be quite weird if dynamically created index silently disappears at some point. This may be obvious for you but not for everyone. We can start with version which does not persist dynamic configuration but looking forward it must be designed with persistence in mind. Probably we can u

Re: IgniteBinary, POJOs and indexing

I don't think we can easily implement this feature. Because it means that we need some kind of "persistent configuration storage", which will be consistent in all the scenarios of failures/restarts. So we have to design this thing first keeping in mind that in the future we will store there not onl

Re: [VOTE] Apache Ignite 1.5.0.final RC3

+1 binding Sergi 2015-12-30 18:53 GMT+03:00 Denis Magda : > +1 (binding) > > > On 12/29/2015 1:54 PM, Anton Vinogradov wrote: > >> Dear Sirs! >> >> We have uploaded release candidate to >> https://dist.apache.org/repos/dist/dev/ignite/1.5.0.final-rc3/ >> >> This is very important release contain

Re: GridFunc.view

c 29, 2015 at 6:12 AM, Sergi Vladykin > wrote: > > > Cool :) > > > > Sergi > > > > 2015-12-29 17:08 GMT+03:00 Vladimir Ozerov : > > > > > I created ticket for this several days ago: > > > https://issues.apache.org/jira/browse/IGNITE-2

Re: GridFunc.view

Cool :) Sergi 2015-12-29 17:08 GMT+03:00 Vladimir Ozerov : > I created ticket for this several days ago: > https://issues.apache.org/jira/browse/IGNITE-2263 > > On Tue, Dec 29, 2015 at 5:05 PM, Sergi Vladykin > wrote: > > > Guys, > > > > We have quite a few

GridFunc.view

Guys, We have quite a few usages of *F.view* in the project. I believe this thing is usually harmful for performance and correctness. Better thing would look like: *Collection filter(Collection src, CollectionFactory dstFactory, IgnitePredicate p)* For example it is used in *GridDiscoveryManager

[jira] [Created] (IGNITE-2294) Implement SQL DML (insert, update, delete) cluses.

Sergi Vladykin created IGNITE-2294: -- Summary: Implement SQL DML (insert, update, delete) cluses. Key: IGNITE-2294 URL: https://issues.apache.org/jira/browse/IGNITE-2294 Project: Ignite

Re: Why do we load Hadoop classes in a separate classloader?

Initially this was done to support multithreaded model of running tasks vs the original multiprocess model of Hadoop. And as far as I remember there were attempts to reuse Hadoop classes but they failed. As for high permgen load, it should not actually be that high, number of classloaders should b

Re: sqlSchema usability question

1. You are actually never use cache name in SQL, you are always use schema name. In case when sqlSchema property is not set it is just derived from cache name. 2. Exactly this happens right now. Property sqlSchema is optional. If you are asking why is it always quoted and case sensitive, that is fo

[jira] [Created] (IGNITE-2177) User defined aggregate functions for SQL

Sergi Vladykin created IGNITE-2177: -- Summary: User defined aggregate functions for SQL Key: IGNITE-2177 URL: https://issues.apache.org/jira/browse/IGNITE-2177 Project: Ignite Issue Type

Re: Introduction

Welcome, Ilya! Should you have any questions, feel free to ask here. Sergi 2015-12-14 12:14 GMT+03:00 Ilya Lantukh : > Dear Igniters, > > My name is Ilya Lantukh, I am a Java Developer from St. Petersburg, Russia > and I've recently joined the Apache Ignite community. > I hope to find here a lo

Re: EA versioning

k wrote: > > On Sun, Dec 06, 2015 at 11:30AM, Sergi Vladykin wrote: > > > Cos and Brane, > > > > > > This issue arised not from our feeling of beautiful, but from practical > > > reasons, > > > namely we need to conform existing Maven and OSGi ve

Re: EA versioning

Cos and Brane, This issue arised not from our feeling of beautiful, but from practical reasons, namely we need to conform existing Maven and OSGi version models at the same time. We did not invent Maven or OSGi, but if we want to play with them well, we have to keep in mind their own quirks and b

Re: EA versioning

Romain, I believe it is a good idea to stick to well-known Maven qualifiers which already exist. *RELEASE* is not in this list and I'd prefer to avoid surprises, if this will be changed later. Also our release cycle is different from Eclipse and Spring (instead of milestones we have betas, but RC

Re: [VOTE] Apache Ignite 1.5.0-b1

+1 Sergi 2015-12-02 16:30 GMT+03:00 Denis Magda : > +1 > > > On 12/2/2015 3:16 PM, Yakov Zhdanov wrote: > >> Dear Sirs! >> >> We have uploaded release candidate to >> https://dist.apache.org/repos/dist/dev/ignite/1.5.0-b1-rc1/ >> >> This is very important release containing initial versions of I

Re: EA versioning

ix at all, e.g. 1.5.0 == 1.5.0-final Sergi > On Tue, Dec 1, 2015 at 10:36 AM, Raul Kripalani wrote: > > > On Tue, Dec 1, 2015 at 5:57 PM, Sergi Vladykin > > > wrote: > > > > > Thanks, Raul! I like your synthesis. > > > > > > We have already ag

<    1   2   3   4   >