Re: Asc and desc index on same field.

I don't really like the idea of having the same index twice because it will consume 2x memory and rarely useful. H2 API does not allow to use the same index for ASC and DESC scans, but probably we can automatically add supplementary fake index which will share the same data structures as original

Re: query configuration design

Dmitriy, May be it makes sense to put the final design on the main page from comments? Sergi 2015-10-26 12:41 GMT+03:00 Dmitriy Setrakyan : > Igniters, > > I want to point out that there is an active discussion going on about query > configuration design here: > > >

Re: Check Ignite code base with Findbugs.

It absolutely does make sense. Of course it will not find complex bugs but it is pretty good at spotting stupid mistakes. Time ago I used to run Eclipse plugin for FindBugs, I believe something alike should exist for Idea as well. Sergi 2015-11-13 17:49 GMT+03:00 Alexey Kuznetsov

Re: Prepared statement concept in indexing

; public API. > > But Dima, note that I saw this "20%" on local benchmark with only 1 node. I > expect that in distributed environment it will be amortized by network. > > On Wed, Nov 4, 2015 at 6:00 PM, Sergi Vladykin <sergi.vlady...@gmail.com> > wrote: > > > Yes

Re: Prepared statement concept in indexing

Yes, it is a problem and I believe after distributed joins feature will be merged, it will become even worse. Though I'd prefer to avoid changing public API for now. I believe it must be enough to cache and reuse parsed query information, generated queries and other stuff. Sergi 2015-11-04

Re: [VOTE] Establishing duration of Apache Ignite Chair rotation

+1 (binding) Sergi 2015-10-14 10:28 GMT+03:00 Raul Kripalani : > +1 (binding) > On 13 Oct 2015 23:27, "Konstantin Boudnik" wrote: > > > Hi! > > > > As discussed in the "[DISCUSS] PMC Chair rotation" thread last month, I > > propose > > that we adopt a rule

Re: Do we need "IgniteCache.randomEntry()" method?

Agree, it is doubtfully useful. Sergi 2015-10-15 17:26 GMT+03:00 Roman : > And another ticket for randomEntry() > https://issues.apache.org/jira/browse/IGNITE-1180 > > > On Thursday, October 15, 2015 9:47 PM, Vladimir Ozerov < > voze...@gridgain.com> wrote: > > >

Re: Data Snapshots in Ignite

Raul, Actually SQL indexes are already snapshotable. I'm not sure if it does make sense to make the whole cache (with full cache API support) snapshotable, but I like your idea about running multiple SQL statements against the same snapshot. Also I don't think that it is a good idea to keep

Re: .Net: separate methods for async operations.

e. Base concepts must be the same across platforms, but > > methods signatures and grouping will be different. > > > > I disagree here. I think consistency matters. Moreover, based on the > previous .NET examples you have provided, I do not see much difference > between .NET

Re: .Net: separate methods for async operations.

In my view we should not pollute sync APIs with all async methods, definitely we have to separate them for better UX. Currently on Java we have IgniteAsyncSupport with method withAsync() which returns the same sync API but that API works in broken manner. Instead it should look like the following

Distributed SQL joins affinity key configuration

Guys, I'm about to finish distributed SQL joins feature for Ignite and we need to decide what to do with configuration because currently I don't see how to change it and not to brake backward compatibility. Currently we declare SQL schema for cache using indexedTypes with annotations or

Re: Name of .Net product

I like "Ignite.NET". Sergi 2015-10-07 15:04 GMT+03:00 Vladimir Ozerov : > Igniters, > > Let's agree on the final name of our .Net product. For now it is referenced > in various places as "Apache Ignite .Net", "Apache Ignite for .Net", > "Apache Ignite .Net platform", etc..

Re: .Net: separate methods for async operations.

I think IgniteAsyncSupport is a big piece of crap even in java, sync/async API separation definitely must be done in another way. Sergi 2015-10-10 0:40 GMT+03:00 Dmitriy Setrakyan : > Pavel, can you explain how .NET async semantics are different from Java? > > On Fri, Oct

Re: .Net: separate methods for async operations.

I actually don't see it as a step in the > opposite direction. I think it achieves the same goal, but in a much > cleaner fashion. Moreover, it seems to be .NET-friendly as well. > > > > > > Regards, > > > > *Raúl Kripalani* > > PMC & Committer @ Apac

Re: API stability.

Guys, As I see it we have 3 types of APIs, that require strong backward compatibility, namely the public API itself (Ignite, IgniteCache, etc...), SPIs (IndexingSpi, DiscoverySpi, etc..) and plugin API (IgnitePlugin, PluginContext, etc...) None of these interfaces provide access to Ignite

Re: Coding style changed!

nton Vinogradov <avinogra...@gridgain.com > > > wrote: > > > Because we should have no mistakes at Ignite Java. > > Checking that build logs contains no "Javadoc Warnings" helps to > guarantee > > that. > > > > On Wed, Sep 2, 2015 at 2:02 PM,

Re: Coding style changed!

> > On Tue, Sep 1, 2015 at 9:21 AM, Denis Magda <dma...@gridgain.com> wrote: > > > I've updated '{ignite_folder}/idea/ignite_codeStyle.xml' to reflect the > > changes. > > > > -- > > Denis > > > > > > On 8/31/2015 5:48 PM, Sergi Vladykin wro

Re: QueryProcessor and CacheProcessor start order

I think it was because caches configured on start must be able to setup SQL schema, so QueryProcessor must be ready. If this not true anymore, then the order can be changed. Sergi 2015-09-03 13:20 GMT+03:00 Yakov Zhdanov : > Sam, I agree. Please try fix components start

Re: QueryProcessor and CacheProcessor start order

with Cache.destroy, but IMO it is not > critical and I don't want to spend time on this now. > > On Thu, Sep 3, 2015 at 10:47 PM, Sergi Vladykin <sergi.vlady...@gmail.com> > wrote: > > > Did you try that fix, Semyon? > > > > I just think that switching start o

Re: Adding compare-and-set method returning value to distributed atomics

Instead of inventing something weird looking I'd better take a closer look at what happens in Java 8 and 9. For example in Java 8 there is already a method AtomicLong.getAndUpdate[1] (paired with updateAndGet of course) which provides the needed semantics. We can implement it reusing known

Re: docker image

rak...@apache.org>: > On Thu, Sep 17, 2015 at 1:39 PM, Sergi Vladykin <sergi.vlady...@gmail.com> > wrote: > > > Probably it means that we should use openjdk by default for development > and > > testing as well? > > > > We can, but I am not sure why we have to. Ca

Re: Adding compare-and-set method returning value to distributed atomics

If something like compareAndSetAndThenAgainGet will not pop up on public Java API, I have no objections :) Sergi 2015-09-17 21:42 GMT+03:00 Vladimir Ozerov : > Lets put getAndUpdate() aside for now, because is not what the question > about. Of course we can add this

Re: Introducing "compatibility level" concept.

For me "compatibility level" looks like a complex and dangerous concept. It really must be enough to have versioned protocol, when newer protocol fully understands older ones. And there is no need to store the protocol version with each object, because it must be enough to send it on handshake

Re: SQL IN operator example

I've submitted the fix. Sergi 2015-09-26 2:33 GMT+03:00 vkulichenko : > Hi Kevin, > > I reproduced the issue and created a ticket [1]. I think it will be fixed > in > the next release. > > [1] https://issues.apache.org/jira/browse/IGNITE-1552 > > -Val > > > > -- >

Re: Coding Guidelines: zookeeper IP finder and mqtt streamer

Agree about checkstyle. I myself do mistakes even after more than 3 years on this code base. Checkstyle is a nice tool, works for many IDEs. For example H2 database requires incoming patches to conform provided checkstyle config, I use it right from Eclipse. Sergi 2015-09-28 16:25 GMT+03:00 Raul

Nodes starts in tests

Guys, A little observation. We have really many tests which start and stop nodes for each test method. Example is IgniteCacheAbstractQuerySelfTest, it contains about 30 test methods and 3 subclasses. In beforeTest method it starts nodes in afterTest it stops them, while cache setup is the same.

Re: Brainstorming about Reactive Streams

Lalit, I don't think we are going to change our APIs to some 3rd party standards or even worse to some 3rd party library. There is already JCache from JSR-107 and I can't say we are 100% happy with it. Thus I can consider Reactive Streams to be an additional optional API but not `All data

Re: SQL Hash indexes

19, 2015 at 2:04 PM, Sergi Vladykin <sergi.vlady...@gmail.com> > wrote: > > > Not necessary, you can configure to have either sorted index or hash > index > > or both. > > In the last case as far as I understand optimizer just will pick up hash > > index for &g

Re: [VOTE] Apache Ignite 1.4.0 Release (RC1)

+1 Sergi 2015-09-25 16:52 GMT+03:00 Alexey Kuznetsov : > +1 > > On Fri, Sep 25, 2015 at 8:48 PM, Anton Vinogradov wrote: > > > +1 > > > > On Fri, Sep 25, 2015 at 3:49 PM, Denis Magda > wrote: > > > > > +1 > > > > > > -Original

Re: Adding compare-and-set method returning value to distributed atomics

Actually I can recall discussions related to this signature on java concurrency interest mailing list, there were some proponents of adding such a method into Atomics, but the final resolution was that it is not that much different from existing compareAndSet to do the needed number of squats (it

SQL Hash indexes

Guys, It seems that for simple equality queries like SELECT * FROM x WHERE a = ? it is more effective to use hash indexes which do not even need to be snapshotable. I think it will be easy to implement one based on ConcurrentHashMap. Thoughts? Sergi

Re: Nodes starts in tests

thus not depending on other tests or test order. > > I believe that this will speed up test execution in many cases. > > D. > > > > > > -- Brane > > > > > > > 2015-09-20 11:00 GMT+03:00 Sergi Vladykin <sergi.vlady...@gmail.com>: > &g

Re: Why IgniteAtomicLong is Closeable?

Agree, really strange. Even method close() without Closeable looks meaningless, if there is method removed() then it must have paired method remove() but not close(). Sergi 2015-09-18 17:22 GMT+03:00 Vladimir Ozerov : > Igniters, > > IgniteAtomicLong extends "Closeable"

Re: EA versioning

11PM, Konstantin Boudnik 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

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

Re: EA versioning

versionatorr.appspot.com/?a=1.5.0-b1=1.5.0-final > > *Raúl Kripalani* > PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and > Messaging Engineer > http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani > http://blog.raulkr.net | twi

Re: EA versioning

the same as having no suffix at all, e.g. 1.5.0 == 1.5.0-final Sergi > On Tue, Dec 1, 2015 at 10:36 AM, Raul Kripalani <ra...@apache.org> wrote: > > > On Tue, Dec 1, 2015 at 5:57 PM, Sergi Vladykin <sergi.vlady...@gmail.com > > > > wrote: > > > >

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

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

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

Re: GridFunc.view

t; D. > > On Tue, Dec 29, 2015 at 6:12 AM, Sergi Vladykin <sergi.vlady...@gmail.com> > wrote: > > > Cool :) > > > > Sergi > > > > 2015-12-29 17:08 GMT+03:00 Vladimir Ozerov <voze...@gridgain.com>: > > > > > I created

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

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

Re: GridFunc.view

Cool :) Sergi 2015-12-29 17:08 GMT+03:00 Vladimir Ozerov <voze...@gridgain.com>: > 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 <sergi.vlady...@gmail.com> > wrote:

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

Re: EA versioning

gt; 1. 1.5.0 == 1.5 > > > >1.5.0 < 1.5.0-EA1 > > > > 2. 1.5.0-EA1 == 1.5-ea-1 > > > >1.5.0-EA1 > 1.5.0-final > > > > 3. 1.5.0-final == 1.5 > > > > --Yakov > > > > 2015-12-01 18:07 GMT+03:00 Sergi Vladykin <serg

Re: EA versioning

The most promising way which should work for both Maven and OSGi is to use *beta* for EA and use *final *for releases. http://versionatorr.appspot.com/?a=1.5.0-final=1.5.0-beta1 http://versionatorr.appspot.com/?a=1.5.0=1.5.0-beta1 Sergi 2015-12-01 18:16 GMT+03:00 Sergi Vladykin <sergi.vl

Re: EA versioning

Also it is an interesting subject with respect to OSGi versioning because Maven and OSGi versions are somewhat conflicting as well. See [1] [1] http://versionatorr.appspot.com/?a=1.5.0-final=1.5.0-ea Sergi 2015-12-01 17:56 GMT+03:00 Raul Kripalani : > It is different when the

Re: EA versioning

FYI, OSGi sorts version qualifiers lexicographically: http://wiki.osgi.org/wiki/Bundle-Version Sergi 2015-12-01 18:55 GMT+03:00 Sergi Vladykin <sergi.vlady...@gmail.com>: > Anton, > > Since we are not going to mix *b1 *with *beta1* this should work well. > >

Re: EA versioning

zelcast's versions ( > http://mvnrepository.com/artifact/com.hazelcast/hazelcast). > > Seems we have to use 'alpha' or use 'ga' at release. Or ignore this case > and recomend users to use explicit version. > > On Tue, Dec 1, 2015 at 5:22 PM, Sergi Vladykin <sergi.vlady...@gmail.com

Re: EA versioning

Raul, This is how Maven works, exactly because of that we want to switch to 1.5.0-b1 instead of 1.5.0-ea 1.5.0 > 1.5.0-b1 Sergi 2015-12-01 19:06 GMT+03:00 Raul Kripalani : > On Tue, Dec 1, 2015 at 3:33 PM, Yakov Zhdanov wrote: > > > 1.5.0-ea > 1.5.0 > >

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

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 <sergi.vlady...@gmail.

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

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

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

Re: Transformers in SCAN queries

SqlFieldsQuery has different definition. So transformers can > be applied to any type of query (including SqlFieldsQuery, I believe). > > On Thu, Feb 4, 2016 at 7:42 PM, Sergi Vladykin <sergi.vlady...@gmail.com> > wrote: > > > I don't like the idea of having additional me

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

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

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

Re: supporting collection indexes

.. What if collection of objects 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 <sergi.vlady...@gmail.com>

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

Re: supporting collection indexes

t would seem like a bad practice as you should split > up the object in such cases. > > Christos. > > > > On 22 Jan 2016, at 10:16, Sergi Vladykin <sergi.vlady...@gmail.com> > wrote: > > > > Yakov, > > > > I absolutely agree that the idea of tryin

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

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

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 <sergi.vlady...@gmail.com>: > +1 to the original proposal

Re: IGNITE-2708

Sorry, sent email before the thread was updated :) Sergi 2016-03-11 8:11 GMT+03:00 Sergi Vladykin <sergi.vlady...@gmail.com>: > 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. >

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

ase review it and/or adjust 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

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

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

Re: Possible optimizations for SQL + Off-heap

> Denis > > On Apr 21, 2016, at 5:27 PM, Sergi Vladykin <sergi.vlady...@gmail.com> > wrote: > > 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 re

Re: SQL statements monitoring and statistics.

Alexey Kuznetsov <akuznet...@gridgain.com>: > 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. > &

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

Re: Enums and SQL queries

engine will have to know how to use it. Is this > possible? > > -Val > > On Fri, Jul 22, 2016 at 10:25 PM, Sergi Vladykin <sergi.vlady...@gmail.com > > wrote: > >> I'm not sure what exactly you are going to patch in SQL engine. We could >> and some SQL function lik

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

Re: Enums and SQL queries

dle Enums automatically. > > 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:4

Re: IGNITE-2294 implementation details

>> > >> >> Sergi > >> >> > >> >> > >> >> > >> >> 2016-07-26 18:24 GMT+03:00 Alexander Paschenko < > >> >> alexander.a.pasche...@gmail.com>: > >> >> > >> >> > I see your point. Bu

Re: IGNITE-2294 implementation details

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

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 <sergi.vlady...@gmail.com>: > I don't think it makes sense to extend JDBC this way because usually if > one have access to Java

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

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

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 <dsetrak...@gridgain.com>: > Sorry, Sergi. What I meant is to file a ticket with the design you > suggested > > Dmitriy > > > > > On Jul 27, 2016, at 9:1

Re: IGNITE-2294 implementation details

ry 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:23 GMT+03:0

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 июля

Re: IGNITE-2294 implementation details

aller support. > > > > - Alex > > > > 2016-07-28 9:08 GMT+03:00 Sergi Vladykin <sergi.vlady...@gmail.com>: > >> I had a quick look at the PR. > >> > >> I don't like this @QueryCacheKey and setKeyProp method on public API. > They > >> so

Re: IGNITE-2294 implementation details

t; - 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 streamer. >

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

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

Re: Distributed joins for JDBC

n string parser. > > Corresponding ticket created IGNITE-3563 ( > https://issues.apache.org/jira/browse/IGNITE-3563 ). > > On Mon, Jul 25, 2016 at 10:04 AM, Sergi Vladykin <sergi.vlady...@gmail.com > > > wrote: > > > I don't think it makes sense to extend JDBC this way b

Re: IGNITE-2294 implementation details

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

Re: IGNITE-2294 implementation details

uery is used in JDBC driver. Thanks. > > - Alex > > 2016-07-27 13:02 GMT+03:00 Sergi Vladykin <sergi.vlady...@gmail.com>: > > Where did you see R in SqlFieldsQuery? > > > > Sergi > > > > 2016-07-27 12:59 GMT+03:00 Alexander Paschenko < > > al

Re: Enums and SQL queries

ither String or Enum as 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,

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

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

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

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 <sergi.vlady...@gmail.com>: > Why do we need to count query arguments? Can anyone clarify?

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

  1   2   3   4   >