[jira] [Created] (IGNITE-11317) Document that SQL DML statements (UPDATE/MERGE) cannot update key fields
Vladimir Ozerov created IGNITE-11317: Summary: Document that SQL DML statements (UPDATE/MERGE) cannot update key fields Key: IGNITE-11317 URL: https://issues.apache.org/jira/browse/IGNITE-11317 Project: Ignite Issue Type: Task Components: documentation, sql Reporter: Vladimir Ozerov Assignee: Artem Budnikov This is architectural limitation which is unlikely to be resolved in the nearest time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11318) Web console: add viewport meta tag
Ilya Borisov created IGNITE-11318: - Summary: Web console: add viewport meta tag Key: IGNITE-11318 URL: https://issues.apache.org/jira/browse/IGNITE-11318 Project: Ignite Issue Type: Improvement Components: wizards Reporter: Ilya Borisov Assignee: Ilya Borisov Web console does not scale automatically on mobile devices, so I propose to add [viewport meta tag|https://developer.mozilla.org/en-US/docs/Mozilla/Mobile/Viewport_meta_tag]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11319) ignitevisorcmd can't handle incorrect !q parameter
Ilya Suntsov created IGNITE-11319:
-
Summary: ignitevisorcmd can't handle incorrect !q parameter
Key: IGNITE-11319
URL: https://issues.apache.org/jira/browse/IGNITE-11319
Project: Ignite
Issue Type: Task
Reporter: Ilya Suntsov
Please take a look at difference between "!q" and "\q" parameters:
{noformat}
visor> !q
[ERROR] Could not expand event
java.lang.IllegalArgumentException: !q: event not found
at jline.console.ConsoleReader.expandEvents(ConsoleReader.java:779)
at jline.console.ConsoleReader.finishBuffer(ConsoleReader.java:631)
at jline.console.ConsoleReader.accept(ConsoleReader.java:2019)
at jline.console.ConsoleReader.readLine(ConsoleReader.java:2666)
at jline.console.ConsoleReader.readLine(ConsoleReader.java:2269)
at
org.apache.ignite.visor.commands.VisorConsole.mainLoop(VisorConsole.scala:214)
at
org.gridgain.visor.commands.VisorGridGainConsole$.delayedEndpoint$org$gridgain$visor$commands$VisorGridGainConsole$1(VisorGridGainConsole.scala:88)
at
org.gridgain.visor.commands.VisorGridGainConsole$delayedInit$body.apply(VisorGridGainConsole.scala:77)
at scala.Function0$class.apply$mcV$sp(Function0.scala:34)
at scala.runtime.AbstractFunction0.apply$mcV$sp(AbstractFunction0.scala:12)
at scala.App$$anonfun$main$1.apply(App.scala:76)
at scala.App$$anonfun$main$1.apply(App.scala:76)
at scala.collection.immutable.List.foreach(List.scala:392)
at
scala.collection.generic.TraversableForwarder$class.foreach(TraversableForwarder.scala:35)
at scala.App$class.main(App.scala:76)
at
org.gridgain.visor.commands.VisorGridGainConsole$.main(VisorGridGainConsole.scala:77)
at
org.gridgain.visor.commands.VisorGridGainConsole.main(VisorGridGainConsole.scala)
visor> \q
[WARN ] Invalid command name: '\q'
[WARN ] Type 'help' to print commands list.
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: [DISCUSSION] [IGNITE-11141] The new java method to create a cache from a template
Sounds good, I agree with naming and marking *addCacheConfiguration* method
as deprecated with replacing on *addCacheConfigurationTemplate*.
Stanislav, could you please look at this?
Thank you,
Sergey
чт, 14 февр. 2019 г. в 01:49, Eduard Shangareev :
> CacheConfiguration cfg = ignite.cacheConfiguration("myTemplate");
> cfg.setName("myCacheFromTemplate");
> ignite.createCache(cfg);
>
> Ok, I got it. We already have addCacheConfiguration and cacheConfiguration
> should be a getter-like counterpart for it.
>
> So, I would suggest deprecating this addCacheConfiguration method and add
> new one Ignite.addCacheTemplate and its counterpart getCacheTemplate.
> Because cacheConfiguration looks very weird, I would expect that it should
> return cache configuration for any given cache name.
>
>
> Thoughts?
>
>
> On Thu, Feb 14, 2019 at 12:01 AM Sergey Moldachev <
> sergeymoldac...@gmail.com>
> wrote:
>
> > Hi, Eduard, thank you for your reply!
> >
> > You can find example and full description in the Jira task
> > . Also you can find
> > simple implementation in comments.
> >
> > Thank you,
> > Sergey!
> >
> > + update subject (fixed a typo)
> >
> > ср, 13 февр. 2019 г. в 19:55, Eduard Shangareev <
> > eduard.shangar...@gmail.com
> > >:
> >
> > > Hi, Sergey!
> > >
> > > Could you give some example of how it is supposed to use?
> > >
> > > On Wed, Feb 13, 2019 at 6:02 PM Sergey Moldachev <
> > > sergeymoldac...@gmail.com>
> > > wrote:
> > >
> > > > Hi, Igniters!
> > > >
> > > > I want to add the new java method *cacheConfiguration(String
> > cacheName)*
> > > in
> > > > to *Ignite* core interface as part of the task
> > > > https://issues.apache.org/jira/browse/IGNITE-11141.
> > > >
> > > > I'll be glad to see the comments about this feature.
> > > >
> > > > Thank you,
> > > > Sergey
> > > >
> > >
> >
>
Re: Code inspection
Hello, Ivan. > Requirements for a prototype code are not the same as for a patch ready to merge True. > I do not see much need in writing good javadocs for prototype. We, as a community, can't force you to do it. > Why should I stub it to be able run any build on TC? Should the community spend TC resources for prototype? You always can check tests for your prototype locally. And when it's ready, at least from code style point of view run it on TC. I, personally, always try to follow project code style, even for prototypes. But, If our code style is not convinient for every day coding for many contributors, should you initiate discussion to change it? ср, 13 февр. 2019 г. в 16:45, Павлухин Иван : > Maxim, > > Oh, my poor tabs.. Joke. > > I am totally ok with currently enabled checks. But I am mostly > concerned about a general approach. I would like to outline one thing. > Requirements for a prototype code are not the same as for a patch > ready to merge (see a little bit more in the end of that message). > > We have a document defining code style which every contributor should > follow [1]. And many points can be checked automatically. Personally, > I do not see much need in writing good javadocs for prototype. Why > should I stub it to be able run any build on TC? > > Also, we a have a review process which should be applied to every > patch. Partially it is described in [2]. And due to this process every > patch should not introduce new failures on TC. So, the patch should > not be merged if inspections failed. > > P.S. Something more about prototypes and production code. There is a > common bad practice in software engineering. It is turning prototypes > into production code. Often it is much faster to create a prototype by > price of violating some rules of writing "clean code". And often > prototype after successful piloting is turned into production code. > And it is very easy in practice to keep some pieces of initially > "dirty" prototype code. I believe human factor plays a great role > here. How should it be done right then? In my opinion good production > code should be designed as "good production code" from the beginning. > So, only ideas are taken from the prototype and a code is fully > rewritten. > > [1] https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines > [2] https://cwiki.apache.org/confluence/display/IGNITE/Review+Checklist > > ср, 13 февр. 2019 г. в 15:05, Maxim Muzafarov : > > > > Ivan, > > > > As the first implementation of this addition, I'd prefer to make it > > working like _Licenses Headers_ suite check. It will fail when some of > > the code style checks violated. Moreover, these licenses header checks > > can be included in the checkstyle plugin configuration. > > > > In general, I'd prefer to have a compilation fail error with code > > style checks and after we will get a stable checkstyle suite I propose > > to change it in a "compilation error" way. If we are talking about the > > coding style convenient for most of the community members I see no > > difference with coding sketches or production-ready branches equally. > > Indeed, no one will be against unused imports [or spaces instead of > > tabs :-) ] in their PRs or prototypes, right? (for instance, it can be > > automatically removed by IDE at commit phase). > > > > Please, note currently enabled checks are: > > - list.isEmpty() instead of list.size() == 0 > > - unused imports > > - missing @Override > > - sotred modifiers checks (e.g. pulic static final ..) > > - redundunt suppersion checks > > - spaces insted of tabs. > > > > Are you really what to violate these checks in your sketches? Hope not > :-) > > > > On Wed, 13 Feb 2019 at 10:25, Nikolay Izhikov > wrote: > > > > > > Actually, I dont see anything wrong with failing *compilation* task. > > > > > > I think one should use project code style for everyday coding, not > only for > > > ready-to-merge PRs. > > > > > > If we cant use code style for everyday coding, we should change the > > > codestyle. > > > > > > What do you think? > > > > > > ср, 13 февр. 2019 г., 10:11 Petr Ivanov mr.wei...@gmail.com: > > > > > > > I guess that was about failing build configuration with Checkstype, > not > > > > compilation build itself. > > > > > > > > > On 12 Feb 2019, at 18:03, Павлухин Иван > wrote: > > > > > > > > > > Folks, > > > > > > > > > > Are you going to fail job compiling Ignite sources [1] if some > > > > > inspection found a problem? Can we avoid it? It is quite common > > > > > pattern to start some feature implementation with making a sketch > and > > > > > running tests against it. I found it convenient to skip some style > > > > > requirements for such sketches (e.g. well formed javadocs). > > > > > > > > > > [1] > > > > > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite > > > > > > > > > > пн, 11 февр. 2019 г. в 11:38, Nikolay Izhikov >: > > > > >> > > > > >> Petr, we should have 1 co
Re: Running single test multiple times on TeamCity
I'd recommend move the IgniteReproducingSuite to separate module to be able use it for all modules. For example, at the moment, we are not able use the suite to run tests from 'indexing' module because of lack dependency. On Thu, Feb 14, 2019 at 10:38 AM Павлухин Иван wrote: > > Ed, > > Thank you for pointing out IgniteReproducingSuite. It looks like it > fits my needs. Do you we have a ticket for bringing back TC > configuration? Should I create one? > > ср, 13 февр. 2019 г. в 17:33, Eduard Shangareev : > > > > Ivan, > > We already have IgniteReproducingSuite, and there was a corresponding TC > > configuration, but it was removed (maybe by accident). > > We could resurrect TC configuration. > > + We can improve Suite to provide test class name by parameter instead of > > changing code. > > > > On Mon, Feb 11, 2019 at 11:22 AM Павлухин Иван wrote: > > > > > Vlad, > > > > > > Your case is valid as well. And DebugSuite will not help there. But I > > > talk about another case. And I have already reproduced several tests > > > after repetitive execution of a single test on TC. So, my case also > > > seems valid. > > > > > > пн, 11 февр. 2019 г. в 10:43, Vladislav Pyatkov : > > > > > > > > Hi, > > > > > > > > I think more test falling on TC due to context in which running. > > > > If you added it in debug suite, it can stop failing anymore like local > > > run. > > > > > > > > On Mon, Feb 11, 2019 at 9:37 AM Павлухин Иван > > > wrote: > > > > > > > > > Hi, > > > > > > > > > > During a couple of last weeks I was fixing several flaky tests. > > > > > Sometimes it was quite hard to reproduce a test locally. So, one > > > > > option was running a particular test on TC several times in a row. To > > > > > setup such run I did code modifications in several places. > > > > > > > > > > I thought about how to simplify the thing. And I came up with some > > > > > sort of solution which I would like to share. Basically it is custom > > > > > junit runner DebugSuite and a configuration annotation > > > > > DebugSuite.Config which allows to choose a method to run and number of > > > > > executions. You can see a draft in PR [1]. > > > > > > > > > > As always there are several options to solve a problem. One > > > > > alternative way is creating something similar to parameterized build > > > > > job Jenkins employs [2] (I have not checked for TC analog yet) and > > > > > using maven features to run single test repeatedly (have not checked > > > > > as well). But all in all we need to answer following questions: > > > > > 1. Do we need such tool? (Or perhaps we already have something and > > > > > there is no need to reinvent the wheel.) > > > > > 2. What is the best way for us to implement the tool? > > > > > > > > > > [1] https://github.com/apache/ignite/pull/6076 > > > > > [2] https://wiki.jenkins.io/display/JENKINS/Parameterized+Build > > > > > > > > > > -- > > > > > Best regards, > > > > > Ivan Pavlukhin > > > > > > > > > > > > > > > > > -- > > > > Vladislav Pyatkov > > > > > > > > > > > > -- > > > Best regards, > > > Ivan Pavlukhin > > > > > > > -- > Best regards, > Ivan Pavlukhin -- Best Regards, Vyacheslav D.
Re: Code inspection
Nikolay, > Should the community spend TC resources for prototype? Why not? I think it is not bad idea to run all tests against some changes into core classes. If I have a clever idea which is easy to test drive I can do couple of prototype-test iterations. If tests shows me that everything is bad then the idea was not so clever and easy. But if I was lucky then I should discuss the idea with other Igniters. I think it is the cheapest way to check the idea because the check is fully automated. Requiring a human feedback is much more expensive in my opinion. > But, If our code style is not convinient for every day coding for many > contributors, should you initiate discussion to change it? Generally I am fine with our codestyle requirements. Also, I would like to keep a focus on the subject. Could you please outline the benefits you see of failing compilation and skipping tests execution if inspections detect a problem? чт, 14 февр. 2019 г. в 14:14, Nikolay Izhikov : > > Hello, Ivan. > > > Requirements for a prototype code are not the same as for a patch ready > to merge > > True. > > > I do not see much need in writing good javadocs for prototype. > > We, as a community, can't force you to do it. > > > Why should I stub it to be able run any build on TC? > > Should the community spend TC resources for prototype? > You always can check tests for your prototype locally. > > And when it's ready, at least from code style point of view run it on TC. > > I, personally, always try to follow project code style, even for prototypes. > But, If our code style is not convinient for every day coding for many > contributors, should you initiate discussion to change it? > > > ср, 13 февр. 2019 г. в 16:45, Павлухин Иван : > > > Maxim, > > > > Oh, my poor tabs.. Joke. > > > > I am totally ok with currently enabled checks. But I am mostly > > concerned about a general approach. I would like to outline one thing. > > Requirements for a prototype code are not the same as for a patch > > ready to merge (see a little bit more in the end of that message). > > > > We have a document defining code style which every contributor should > > follow [1]. And many points can be checked automatically. Personally, > > I do not see much need in writing good javadocs for prototype. Why > > should I stub it to be able run any build on TC? > > > > Also, we a have a review process which should be applied to every > > patch. Partially it is described in [2]. And due to this process every > > patch should not introduce new failures on TC. So, the patch should > > not be merged if inspections failed. > > > > P.S. Something more about prototypes and production code. There is a > > common bad practice in software engineering. It is turning prototypes > > into production code. Often it is much faster to create a prototype by > > price of violating some rules of writing "clean code". And often > > prototype after successful piloting is turned into production code. > > And it is very easy in practice to keep some pieces of initially > > "dirty" prototype code. I believe human factor plays a great role > > here. How should it be done right then? In my opinion good production > > code should be designed as "good production code" from the beginning. > > So, only ideas are taken from the prototype and a code is fully > > rewritten. > > > > [1] https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines > > [2] https://cwiki.apache.org/confluence/display/IGNITE/Review+Checklist > > > > ср, 13 февр. 2019 г. в 15:05, Maxim Muzafarov : > > > > > > Ivan, > > > > > > As the first implementation of this addition, I'd prefer to make it > > > working like _Licenses Headers_ suite check. It will fail when some of > > > the code style checks violated. Moreover, these licenses header checks > > > can be included in the checkstyle plugin configuration. > > > > > > In general, I'd prefer to have a compilation fail error with code > > > style checks and after we will get a stable checkstyle suite I propose > > > to change it in a "compilation error" way. If we are talking about the > > > coding style convenient for most of the community members I see no > > > difference with coding sketches or production-ready branches equally. > > > Indeed, no one will be against unused imports [or spaces instead of > > > tabs :-) ] in their PRs or prototypes, right? (for instance, it can be > > > automatically removed by IDE at commit phase). > > > > > > Please, note currently enabled checks are: > > > - list.isEmpty() instead of list.size() == 0 > > > - unused imports > > > - missing @Override > > > - sotred modifiers checks (e.g. pulic static final ..) > > > - redundunt suppersion checks > > > - spaces insted of tabs. > > > > > > Are you really what to violate these checks in your sketches? Hope not > > :-) > > > > > > On Wed, 13 Feb 2019 at 10:25, Nikolay Izhikov > > wrote: > > > > > > > > Actually, I dont see anything wrong with failing *compilation* task. > >
Re: [DISCUSSION] [IGNITE-11141] The new java method to create a cache from a template
Hello!
What about existing convention of using asterisk to mark templates? How
does it integerate with this one?
Regards,
--
Ilya Kasnacheev
чт, 14 февр. 2019 г. в 13:04, Sergey Moldachev :
> Sounds good, I agree with naming and marking *addCacheConfiguration* method
> as deprecated with replacing on *addCacheConfigurationTemplate*.
>
> Stanislav, could you please look at this?
>
> Thank you,
> Sergey
>
> чт, 14 февр. 2019 г. в 01:49, Eduard Shangareev <
> eduard.shangar...@gmail.com
> >:
>
> > CacheConfiguration cfg = ignite.cacheConfiguration("myTemplate");
> > cfg.setName("myCacheFromTemplate");
> > ignite.createCache(cfg);
> >
> > Ok, I got it. We already have addCacheConfiguration and
> cacheConfiguration
> > should be a getter-like counterpart for it.
> >
> > So, I would suggest deprecating this addCacheConfiguration method and add
> > new one Ignite.addCacheTemplate and its counterpart getCacheTemplate.
> > Because cacheConfiguration looks very weird, I would expect that it
> should
> > return cache configuration for any given cache name.
> >
> >
> > Thoughts?
> >
> >
> > On Thu, Feb 14, 2019 at 12:01 AM Sergey Moldachev <
> > sergeymoldac...@gmail.com>
> > wrote:
> >
> > > Hi, Eduard, thank you for your reply!
> > >
> > > You can find example and full description in the Jira task
> > > . Also you can
> find
> > > simple implementation in comments.
> > >
> > > Thank you,
> > > Sergey!
> > >
> > > + update subject (fixed a typo)
> > >
> > > ср, 13 февр. 2019 г. в 19:55, Eduard Shangareev <
> > > eduard.shangar...@gmail.com
> > > >:
> > >
> > > > Hi, Sergey!
> > > >
> > > > Could you give some example of how it is supposed to use?
> > > >
> > > > On Wed, Feb 13, 2019 at 6:02 PM Sergey Moldachev <
> > > > sergeymoldac...@gmail.com>
> > > > wrote:
> > > >
> > > > > Hi, Igniters!
> > > > >
> > > > > I want to add the new java method *cacheConfiguration(String
> > > cacheName)*
> > > > in
> > > > > to *Ignite* core interface as part of the task
> > > > > https://issues.apache.org/jira/browse/IGNITE-11141.
> > > > >
> > > > > I'll be glad to see the comments about this feature.
> > > > >
> > > > > Thank you,
> > > > > Sergey
> > > > >
> > > >
> > >
> >
>
Re: Make the TeamCity console quiet.
Maksim, I tried configuration with quite console and unlimited log file on my machine. Naively configured in log4j-test.xml it works not so fine in development environment because log file is appended by each test execution. Console redirection works better in development environment. Should we have separate log config for TC? By the way log redirection does not work well for every test in development environment. Sometimes it seems that it could be easier to work with file. Sometimes IDEA shrinks console logs. Igniters, do you have ideas how to work with logs produced by tests more convenient? пн, 11 февр. 2019 г. в 17:29, Eduard Shangareev : > > Maksim, > > sounds good. > > 1) Can we just turn off log rollover? > 2) I believe, that we need the ability to override this by setting > parameter for Run All. > > > > On Mon, Feb 11, 2019 at 4:12 PM Maksim Stepachev > wrote: > > > Ivan, > > > > Yes. It happens because we use the RollingFileAppender for a file logging. > > This appender has the next properties: > > > > > > > > > > Can I increase MaxFileSize by 200MB or more? I suppose these limits were > > added for cases when the test writes a log. It makes the guarantee that > > logs less than 10*10 = 100MBs. But it's wrong if it writes into the console > > too. > > > > пн, 11 февр. 2019 г. в 13:14, Павлухин Иван : > > > > > Maksim, > > > > > > Generally I like the idea. But there is one thing which bothers me a > > > little bit. Usually I use "Download full build log" link to download > > > log and then examine it as a single file. AFAIK artifact with logs > > > contains several files. Could you suggest a way how can I conveniently > > > explore files archive as a single file? > > > > > > пн, 11 февр. 2019 г. в 13:04, Ilya Kasnacheev > >: > > > > > > > > Hello! > > > > > > > > Can we do IGNITE_QUIET=true for runAlls triggered by bot (along with > > > > SCALE_FACTOR) and false for manually triggered builds (or retriggered > > > > failures)? > > > > > > > > Regards, > > > > -- > > > > Ilya Kasnacheev > > > > > > > > > > > > пн, 11 февр. 2019 г. в 13:03, Dmitriy Pavlov : > > > > > > > > > ++1 from my side. It is very interesting how overall RunAll run time > > > will > > > > > be decreased. > > > > > > > > > > My previous experience with TeamCity shows that removing pressure > > from > > > the > > > > > console and using adequate logging instead may bring x1.5 - x2 > > > performance > > > > > boost for tests. > > > > > > > > > > One more benefit of moving from synced streams to async logging will > > > show > > > > > us that bugs, which we can't see right now. > > > > > > > > > > So I absolutely agree to move logging data to a logger. > > > > > > > > > > пн, 11 февр. 2019 г. в 11:14, Maksim Stepachev < > > > maksim.stepac...@gmail.com > > > > > >: > > > > > > > > > > > Igniters, > > > > > > > > > > > > > > > > > > When I was working with flaky tests, I was surprised that one of > > the > > > > > > reasons for failure was a log appender blocking the console. > > > > > > > > > > > > > > > > > > I suppose it happened because of a TeamCity agent communicating > > with > > > java > > > > > > out through Linux pipe. This is a problem for tests with 1GB log > > > history. > > > > > > > > > > > > > > > > > > Our test by default writes logs into 2 sources, such as the console > > > and > > > > > the > > > > > > file. I'm going to change mode for the console at IGNITE_QUIET=true > > > and > > > > > > write only warn and error logs in it. Also, I’ll include a > > > diagnostic log > > > > > > into it. > > > > > > > > > > > > > > > > > > You will be able to read the previous log from the Artifacts tab in > > > your > > > > > > build. > > > > > > > > > > > > This is a solution which has advantages: > > > > > > > > > > > > 1. First of all, we’ll cut down the space usage pre-test run by > > ~6-7 > > > > > times. > > > > > > For example - it's 1GB of saved space for 1 suit like "Cache > > > (Restarts) > > > > > 1". > > > > > > > > > > > > 2. We’ll be able to use a new space for long history storage for > > > builds. > > > > > > > > > > > > 3. The TeamCity bot won't be lagging when it parses a large file. > > > > > > > > > > > > 4. Possibly some of tests won't be flaky. > > > > > > > > > > > > 5. And finally, the time of running my suite will be cut down by > > 5-7 > > > > > > minutes. > > > > > > > > > > > > > > > > > > Also, I'm going to make a workaround for previous behavior. For > > > example, > > > > > > this flag will be added to build params. But I should investigate > > it. > > > > > > > > > > > > > > > > > > > > > > > -- > > > Best regards, > > > Ivan Pavlukhin > > > > > -- Best regards, Ivan Pavlukhin
Re: Code inspection
Ivan, > Could you please outline the benefits you see of failing compilation and skipping tests execution if inspections detect a problem? All community members are forced to follow code style. It's harder to achieve it with dedicated suite. чт, 14 февр. 2019 г. в 15:21, Павлухин Иван : > Nikolay, > > > Should the community spend TC resources for prototype? > Why not? I think it is not bad idea to run all tests against some > changes into core classes. If I have a clever idea which is easy to > test drive I can do couple of prototype-test iterations. If tests > shows me that everything is bad then the idea was not so clever and > easy. But if I was lucky then I should discuss the idea with other > Igniters. I think it is the cheapest way to check the idea because the > check is fully automated. Requiring a human feedback is much more > expensive in my opinion. > > But, If our code style is not convinient for every day coding for many > contributors, should you initiate discussion to change it? > Generally I am fine with our codestyle requirements. > > Also, I would like to keep a focus on the subject. Could you please > outline the benefits you see of failing compilation and skipping tests > execution if inspections detect a problem? > > чт, 14 февр. 2019 г. в 14:14, Nikolay Izhikov : > > > > Hello, Ivan. > > > > > Requirements for a prototype code are not the same as for a patch ready > > to merge > > > > True. > > > > > I do not see much need in writing good javadocs for prototype. > > > > We, as a community, can't force you to do it. > > > > > Why should I stub it to be able run any build on TC? > > > > Should the community spend TC resources for prototype? > > You always can check tests for your prototype locally. > > > > And when it's ready, at least from code style point of view run it on TC. > > > > I, personally, always try to follow project code style, even for > prototypes. > > But, If our code style is not convinient for every day coding for many > > contributors, should you initiate discussion to change it? > > > > > > ср, 13 февр. 2019 г. в 16:45, Павлухин Иван : > > > > > Maxim, > > > > > > Oh, my poor tabs.. Joke. > > > > > > I am totally ok with currently enabled checks. But I am mostly > > > concerned about a general approach. I would like to outline one thing. > > > Requirements for a prototype code are not the same as for a patch > > > ready to merge (see a little bit more in the end of that message). > > > > > > We have a document defining code style which every contributor should > > > follow [1]. And many points can be checked automatically. Personally, > > > I do not see much need in writing good javadocs for prototype. Why > > > should I stub it to be able run any build on TC? > > > > > > Also, we a have a review process which should be applied to every > > > patch. Partially it is described in [2]. And due to this process every > > > patch should not introduce new failures on TC. So, the patch should > > > not be merged if inspections failed. > > > > > > P.S. Something more about prototypes and production code. There is a > > > common bad practice in software engineering. It is turning prototypes > > > into production code. Often it is much faster to create a prototype by > > > price of violating some rules of writing "clean code". And often > > > prototype after successful piloting is turned into production code. > > > And it is very easy in practice to keep some pieces of initially > > > "dirty" prototype code. I believe human factor plays a great role > > > here. How should it be done right then? In my opinion good production > > > code should be designed as "good production code" from the beginning. > > > So, only ideas are taken from the prototype and a code is fully > > > rewritten. > > > > > > [1] > https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines > > > [2] > https://cwiki.apache.org/confluence/display/IGNITE/Review+Checklist > > > > > > ср, 13 февр. 2019 г. в 15:05, Maxim Muzafarov : > > > > > > > > Ivan, > > > > > > > > As the first implementation of this addition, I'd prefer to make it > > > > working like _Licenses Headers_ suite check. It will fail when some > of > > > > the code style checks violated. Moreover, these licenses header > checks > > > > can be included in the checkstyle plugin configuration. > > > > > > > > In general, I'd prefer to have a compilation fail error with code > > > > style checks and after we will get a stable checkstyle suite I > propose > > > > to change it in a "compilation error" way. If we are talking about > the > > > > coding style convenient for most of the community members I see no > > > > difference with coding sketches or production-ready branches equally. > > > > Indeed, no one will be against unused imports [or spaces instead of > > > > tabs :-) ] in their PRs or prototypes, right? (for instance, it can > be > > > > automatically removed by IDE at commit phase). > > > > > > > > Please, note currently en
[jira] [Created] (IGNITE-11320) JDBC Thin: add support for individual reconnect in case of best effort affinity mode.
Alexander Lapin created IGNITE-11320: Summary: JDBC Thin: add support for individual reconnect in case of best effort affinity mode. Key: IGNITE-11320 URL: https://issues.apache.org/jira/browse/IGNITE-11320 Project: Ignite Issue Type: Task Components: jdbc Reporter: Alexander Lapin Fix For: 2.8 Currently in case of best effort affinity mode we either connect to all nodes specified by user or throw SQLException. Given logic needs to be improved. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11321) JDBC Thin: implement nodes multi version support in case of best effort affinity mode.
Alexander Lapin created IGNITE-11321: Summary: JDBC Thin: implement nodes multi version support in case of best effort affinity mode. Key: IGNITE-11321 URL: https://issues.apache.org/jira/browse/IGNITE-11321 Project: Ignite Issue Type: Task Components: jdbc Reporter: Alexander Lapin Fix For: 2.8 Currently in case of best effort affinity mode we throw SQLException if the version of any of the nodes to which we connect is different from the version of all other nodes.Given logic needs to be improved. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11322) [USABILITY] Extend Node FAILED message by add consistentId if it exist
ARomantsov created IGNITE-11322: --- Summary: [USABILITY] Extend Node FAILED message by add consistentId if it exist Key: IGNITE-11322 URL: https://issues.apache.org/jira/browse/IGNITE-11322 Project: Ignite Issue Type: Bug Affects Versions: 2.7 Reporter: ARomantsov Fix For: 2.8 Now I having only this [GridDiscoveryManager] Node FAILED: TcpDiscoveryNode [id=f8cd73a1-8da5-4a07-b298-55634dd7c9f8, addrs=ArrayList [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, lastExchangeTime=1550141566893, loc=false, isClient=false] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Code inspection
Nikolay, > All community members are forced to follow code style. It's harder to achieve > it with dedicated suite. Why it is easier to follow code style with use of maven checkstyle plugin? Is it integrated into IDEA out of box? As I got it additional IDEA plugin is needed as well. Who will enforce everybody to install it? Also, as I see a common good practice today is using TC Bot visa. Visa includes result from running inspections job. чт, 14 февр. 2019 г. в 16:08, Nikolay Izhikov : > > Ivan, > > > Could you please outline the benefits you see of failing compilation and > skipping tests execution if inspections detect a problem? > > All community members are forced to follow code style. > It's harder to achieve it with dedicated suite. > > > чт, 14 февр. 2019 г. в 15:21, Павлухин Иван : > > > Nikolay, > > > > > Should the community spend TC resources for prototype? > > Why not? I think it is not bad idea to run all tests against some > > changes into core classes. If I have a clever idea which is easy to > > test drive I can do couple of prototype-test iterations. If tests > > shows me that everything is bad then the idea was not so clever and > > easy. But if I was lucky then I should discuss the idea with other > > Igniters. I think it is the cheapest way to check the idea because the > > check is fully automated. Requiring a human feedback is much more > > expensive in my opinion. > > > But, If our code style is not convinient for every day coding for many > > contributors, should you initiate discussion to change it? > > Generally I am fine with our codestyle requirements. > > > > Also, I would like to keep a focus on the subject. Could you please > > outline the benefits you see of failing compilation and skipping tests > > execution if inspections detect a problem? > > > > чт, 14 февр. 2019 г. в 14:14, Nikolay Izhikov : > > > > > > Hello, Ivan. > > > > > > > Requirements for a prototype code are not the same as for a patch ready > > > to merge > > > > > > True. > > > > > > > I do not see much need in writing good javadocs for prototype. > > > > > > We, as a community, can't force you to do it. > > > > > > > Why should I stub it to be able run any build on TC? > > > > > > Should the community spend TC resources for prototype? > > > You always can check tests for your prototype locally. > > > > > > And when it's ready, at least from code style point of view run it on TC. > > > > > > I, personally, always try to follow project code style, even for > > prototypes. > > > But, If our code style is not convinient for every day coding for many > > > contributors, should you initiate discussion to change it? > > > > > > > > > ср, 13 февр. 2019 г. в 16:45, Павлухин Иван : > > > > > > > Maxim, > > > > > > > > Oh, my poor tabs.. Joke. > > > > > > > > I am totally ok with currently enabled checks. But I am mostly > > > > concerned about a general approach. I would like to outline one thing. > > > > Requirements for a prototype code are not the same as for a patch > > > > ready to merge (see a little bit more in the end of that message). > > > > > > > > We have a document defining code style which every contributor should > > > > follow [1]. And many points can be checked automatically. Personally, > > > > I do not see much need in writing good javadocs for prototype. Why > > > > should I stub it to be able run any build on TC? > > > > > > > > Also, we a have a review process which should be applied to every > > > > patch. Partially it is described in [2]. And due to this process every > > > > patch should not introduce new failures on TC. So, the patch should > > > > not be merged if inspections failed. > > > > > > > > P.S. Something more about prototypes and production code. There is a > > > > common bad practice in software engineering. It is turning prototypes > > > > into production code. Often it is much faster to create a prototype by > > > > price of violating some rules of writing "clean code". And often > > > > prototype after successful piloting is turned into production code. > > > > And it is very easy in practice to keep some pieces of initially > > > > "dirty" prototype code. I believe human factor plays a great role > > > > here. How should it be done right then? In my opinion good production > > > > code should be designed as "good production code" from the beginning. > > > > So, only ideas are taken from the prototype and a code is fully > > > > rewritten. > > > > > > > > [1] > > https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines > > > > [2] > > https://cwiki.apache.org/confluence/display/IGNITE/Review+Checklist > > > > > > > > ср, 13 февр. 2019 г. в 15:05, Maxim Muzafarov : > > > > > > > > > > Ivan, > > > > > > > > > > As the first implementation of this addition, I'd prefer to make it > > > > > working like _Licenses Headers_ suite check. It will fail when some > > of > > > > > the code style checks violated. Moreover, these licenses header > > checks > > > > > can be
RE: [DISCUSSION] [IGNITE-11141] The new java method to create a cache from a template
Sergey, Ed,
On method naming/deprecation/etc.
I would actually like the new method to work for both templates and regular
caches.
For templates it would return a copy of the template.
For existing caches it would return a copy of the cache configuration.
In other words, it would be a shortcut for
`new
CacheConfiguration(ignite.cache("foo").configuration(CacheConfiguration.class))`
I wouldn't expect it to be widely used but I think this adds some uniformity to
the behavior.
Ilya,
On asterisk usage.
If you have a cache config "foo*" in your static cache configurations
then you will be able to get that configuration via
`ignite.cacheConfiguration("foo")` (no asterisk).
Asterisk is being dropped when the template is created. This is how it works
now, no changes here.
All,
Regarding reshuffling all this in 3.0.
I would
- change method name addCacheConfiguration to addCacheTemplate
- would add a new property `CacheConfiguration[] cacheTemplates` to put
templates to - instead of putting them
into `cacheConfigutations` with an asterisk
But that's a different topic, I think.
Thanks,
Stan
> -Original Message-
> From: Ilya Kasnacheev
> Sent: Thursday, February 14, 2019 3:32 PM
> To: dev@ignite.apache.org
> Subject: Re: [DISCUSSION] [IGNITE-11141] The new java method to create a
> cache from a template
>
> Hello!
>
> What about existing convention of using asterisk to mark templates? How
> does it integerate with this one?
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> чт, 14 февр. 2019 г. в 13:04, Sergey Moldachev
> :
>
> > Sounds good, I agree with naming and marking *addCacheConfiguration*
> method
> > as deprecated with replacing on *addCacheConfigurationTemplate*.
> >
> > Stanislav, could you please look at this?
> >
> > Thank you,
> > Sergey
> >
> > чт, 14 февр. 2019 г. в 01:49, Eduard Shangareev <
> > eduard.shangar...@gmail.com
> > >:
> >
> > > CacheConfiguration cfg = ignite.cacheConfiguration("myTemplate");
> > > cfg.setName("myCacheFromTemplate");
> > > ignite.createCache(cfg);
> > >
> > > Ok, I got it. We already have addCacheConfiguration and
> > cacheConfiguration
> > > should be a getter-like counterpart for it.
> > >
> > > So, I would suggest deprecating this addCacheConfiguration method and
> add
> > > new one Ignite.addCacheTemplate and its counterpart
> getCacheTemplate.
> > > Because cacheConfiguration looks very weird, I would expect that it
> > should
> > > return cache configuration for any given cache name.
> > >
> > >
> > > Thoughts?
> > >
> > >
> > > On Thu, Feb 14, 2019 at 12:01 AM Sergey Moldachev <
> > > sergeymoldac...@gmail.com>
> > > wrote:
> > >
> > > > Hi, Eduard, thank you for your reply!
> > > >
> > > > You can find example and full description in the Jira task
> > > > . Also you can
> > find
> > > > simple implementation in comments.
> > > >
> > > > Thank you,
> > > > Sergey!
> > > >
> > > > + update subject (fixed a typo)
> > > >
> > > > ср, 13 февр. 2019 г. в 19:55, Eduard Shangareev <
> > > > eduard.shangar...@gmail.com
> > > > >:
> > > >
> > > > > Hi, Sergey!
> > > > >
> > > > > Could you give some example of how it is supposed to use?
> > > > >
> > > > > On Wed, Feb 13, 2019 at 6:02 PM Sergey Moldachev <
> > > > > sergeymoldac...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Hi, Igniters!
> > > > > >
> > > > > > I want to add the new java method *cacheConfiguration(String
> > > > cacheName)*
> > > > > in
> > > > > > to *Ignite* core interface as part of the task
> > > > > > https://issues.apache.org/jira/browse/IGNITE-11141.
> > > > > >
> > > > > > I'll be glad to see the comments about this feature.
> > > > > >
> > > > > > Thank you,
> > > > > > Sergey
> > > > > >
> > > > >
> > > >
> > >
> >
Re: Best Effort Affinity for thin clients
Guys, I've updated the IEP page [1] once again.
Please, pay attention to sections Cache affinity mapping acquiring
(4.a, format of Cache Partitions Request) and Changes to cache
operations with single key (3 and 4, algorithm).
Long story short, I've decided to add some additional data to Cache
Partitions Response, so that client can determine how to calculate
partition for a given key properly.
[1] -
https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients
Best Regards,
Igor
On Mon, Feb 4, 2019 at 8:24 PM Pavel Tupitsyn wrote:
> Looks good to me.
>
> On Mon, Feb 4, 2019 at 6:30 PM Igor Sapego wrote:
>
> > I've updated IEP page: [1]
> >
> > What do you think now? To me it looks cleaner.
> >
> > [1] -
> >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients
> >
> > Best Regards,
> > Igor
> >
> >
> > On Mon, Feb 4, 2019 at 4:44 PM Igor Sapego wrote:
> >
> > > Ok, I understand now. I'll try updating IEP according to this proposal
> > and
> > > notify you guys.
> > >
> > > Best Regards,
> > > Igor
> > >
> > >
> > > On Mon, Feb 4, 2019 at 4:27 PM Vladimir Ozerov
> > > wrote:
> > >
> > >> Igor,
> > >>
> > >> My idea is simply to add the list of caches with the same distribution
> > to
> > >> the end of partition response. Client can use this information to
> > populate
> > >> partition info for more caches in a single request.
> > >>
> > >> On Mon, Feb 4, 2019 at 3:06 PM Igor Sapego
> wrote:
> > >>
> > >> > Vladimir,
> > >> >
> > >> > So correct me if I'm wrong, what you propose is to avoid mentioning
> > >> > of cache groups, and use instead of "cache group" term something
> like
> > >> > "distribution"? Or do you propose some changes in protocol? If so,
> can
> > >> > you briefly explain, what kind of changes they are?
> > >> >
> > >> > Best Regards,
> > >> > Igor
> > >> >
> > >> >
> > >> > On Mon, Feb 4, 2019 at 1:13 PM Vladimir Ozerov <
> voze...@gridgain.com>
> > >> > wrote:
> > >> >
> > >> > > Igor,
> > >> > >
> > >> > > Yes, cache groups are public API. However, we try to avoid new
> APIs
> > >> > > depending on them.
> > >> > > The main point from my side is that “similar cache group” can be
> > >> easily
> > >> > > generalized to “similar distribution”. This way we avoid cache
> > groups
> > >> on
> > >> > > protocol level at virtually no cost.
> > >> > >
> > >> > > Vladimir.
> > >> > >
> > >> > > пн, 4 февр. 2019 г. в 12:48, Igor Sapego :
> > >> > >
> > >> > > > Guys,
> > >> > > >
> > >> > > > Can you explain why do we want to avoid Cache groups in
> protocol?
> > >> > > >
> > >> > > > If it's about simplicity of the protocol, then removing cache
> > groups
> > >> > will
> > >> > > > not help much with it - we will still need to include
> > >> "knownCacheIds"
> > >> > > > field in request and "cachesWithTheSamePartitioning" field in
> > >> response.
> > >> > > > And also, since when do Ignite prefers simplicity over
> > performance?
> > >> > > >
> > >> > > > If it's about not wanting to show internals of Ignite then it
> > sounds
> > >> > like
> > >> > > > a very weak argument to me, since Cache Groups is a public thing
> > >> [1].
> > >> > > >
> > >> > > > [1] - https://apacheignite.readme.io/docs/cache-groups
> > >> > > >
> > >> > > > Best Regards,
> > >> > > > Igor
> > >> > > >
> > >> > > >
> > >> > > > On Mon, Feb 4, 2019 at 11:47 AM Vladimir Ozerov <
> > >> voze...@gridgain.com>
> > >> > > > wrote:
> > >> > > >
> > >> > > > > Pavel, Igor,
> > >> > > > >
> > >> > > > > This is not very accurate to say that this will not save
> memory.
> > >> In
> > >> > > > > practice we observed a number of OOME issues on the
> server-side
> > >> due
> > >> > to
> > >> > > > many
> > >> > > > > caches and it was one of motivations for cache groups (another
> > one
> > >> > disk
> > >> > > > > access optimizations). On the other hand, I agree that we'd
> > >> better to
> > >> > > > avoid
> > >> > > > > cache groups in the protocol because this is internal
> > >> implementation
> > >> > > > detail
> > >> > > > > which is likely (I hope so) to be changed in future.
> > >> > > > >
> > >> > > > > So I have another proposal - let's track caches with the same
> > >> > affinity
> > >> > > > > distribution instead. That is, normally most of PARTITIONED
> > caches
> > >> > will
> > >> > > > > have very few variants of configuration: it will be Rendezvous
> > >> > affinity
> > >> > > > > function, most likely with default partition number and with
> 1-2
> > >> > > backups
> > >> > > > at
> > >> > > > > most. So when affinity distribution for specific cache is
> > >> requested,
> > >> > we
> > >> > > > can
> > >> > > > > append to the response *list of caches with the same
> > >> distribution*.
> > >> > > I.e.:
> > >> > > > >
> > >> > > > > class AffinityResponse {
> > >> > > > > Object distribution;// Actual distribution
> > >> > > > > List cacheIds; // Caches with similar
> distribution
> > >> > > > > }
> > >
[jira] [Created] (IGNITE-11323) Reduce boilerplate "System.setProperty" code in tests
Ivan Bessonov created IGNITE-11323:
--
Summary: Reduce boilerplate "System.setProperty" code in tests
Key: IGNITE-11323
URL: https://issues.apache.org/jira/browse/IGNITE-11323
Project: Ignite
Issue Type: Test
Reporter: Ivan Bessonov
Assignee: Ivan Bessonov
There are many examples in tests where some property gets new value in
"beforeTestsStarted"/"beforeTest"/"beginning of test method" and then gets its
previous value in "afterTestsStopped"/"afterTest"/"finally block of test
method". This approach leads to excessive code that can be avoided.
I suggest implementing annotation "WithSystemProperty" (name is the subject to
discussion) that will allow us to write this:
{code:java}
@Test
@WithSystemProperty(key = IGNITE_SKIP_CONFIGURATION_CONSISTENCY_CHECK, value =
"true")
public void testSkipCheckConsistencyFlagEnabled() throws Exception {
...
}
{code}
instead of this:
{code:java}
@Test
public void testSkipCheckConsistencyFlagEnabled() throws Exception {
String backup =
System.setProperty(IGNITE_SKIP_CONFIGURATION_CONSISTENCY_CHECK, "true");
try {
...
}
finally {
if (backup != null)
System.setProperty(IGNITE_SKIP_CONFIGURATION_CONSISTENCY_CHECK,
backup);
else
System.clearProperty(IGNITE_SKIP_CONFIGURATION_CONSISTENCY_CHECK);
}
}
{code}
There's also has to be ability to use this annotation on test class so new
value of system properties will be used in all of its test methods.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[DISCUSSION] Usage of system properties in tests
Hello Igniters,
I'd like to discuss the way we treat system properties in our test codebase.
It's a common pattern where we set system property in "beforeTestsStarted"
and clear it in "afterTestsStopped". Purest example that I've found is class
"RedisProtocolGetAllAsArrayTest".
There are similar things with "beforeTest"/"afterTest" or huge
"try/finally" blocks
right in test methods.
I think that all this code can be avoided and solution might look like this:
@Test
@WithSystemProperty(key = IGNITE_PROPERTY_NAME, value = "true")
public void testSomething() throws Exception {
...
}
Same annotation might be used on class, this way new system property will
be applied to all test methods in the class.
I already created the issue for this change [1] and PR with demo [2]. It
contains
implementation of annotation processing and a few migrated tests. If you
like
the idea then I will migrate all the other tests on the same mechanism.
What do you think?
[1] https://issues.apache.org/jira/browse/IGNITE-11323
[2] https://github.com/apache/ignite/pull/6109
--
Sincerely yours,
Ivan Bessonov
Re: [DISCUSSION] Usage of system properties in tests
I find it absolutely positive and modern approach and good contribution.
Count on my support if you will need any assistance with applying this
patch.
чт, 14 февр. 2019 г. в 18:53, Ivan Bessonov :
> Hello Igniters,
>
> I'd like to discuss the way we treat system properties in our test
> codebase.
> It's a common pattern where we set system property in "beforeTestsStarted"
> and clear it in "afterTestsStopped". Purest example that I've found is
> class
> "RedisProtocolGetAllAsArrayTest".
>
> There are similar things with "beforeTest"/"afterTest" or huge
> "try/finally" blocks
> right in test methods.
>
> I think that all this code can be avoided and solution might look like
> this:
>
> @Test
> @WithSystemProperty(key = IGNITE_PROPERTY_NAME, value = "true")
> public void testSomething() throws Exception {
> ...
> }
>
> Same annotation might be used on class, this way new system property will
> be applied to all test methods in the class.
>
> I already created the issue for this change [1] and PR with demo [2]. It
> contains
> implementation of annotation processing and a few migrated tests. If you
> like
> the idea then I will migrate all the other tests on the same mechanism.
>
> What do you think?
>
> [1] https://issues.apache.org/jira/browse/IGNITE-11323
> [2] https://github.com/apache/ignite/pull/6109
>
> --
> Sincerely yours,
> Ivan Bessonov
>
[jira] [Created] (IGNITE-11324) Getting Started Doc openweather API has changed
Greg created IGNITE-11324: - Summary: Getting Started Doc openweather API has changed Key: IGNITE-11324 URL: https://issues.apache.org/jira/browse/IGNITE-11324 Project: Ignite Issue Type: Task Components: documentation Affects Versions: 2.7 Environment: Ignite 2.7 Java 8.0.201 MacOS 10.14.3 Reporter: Greg Fix For: 2.8 In the Ignite Getting Started Guide ([https://apacheignite.readme.io/docs/getting-started)] the tutorial called First Ignite Grid Application makes use of a public API on samples.openweathermap.org. This URL is no longer valid and the new URL pattern is [http://api.openweathermap.org/.|http://api.openweathermap.org/] If the user calls getCurrentTemperature in WeatherServiceImpl, they will get the following error Weather forecast in London:301 Moved Permanently301 Moved Permanentlyopenresty/1.9.7.1 Please use the new URL for WEATHER_URL in WeatherServiceImpl private static final String WEATHER_URL = "http://api.openweathermap.org/data/2.5/weather?";; -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11325) SQL: Single place to start missing caches (H2Utils.checkAndStartNotStartedCache)
Vladimir Ozerov created IGNITE-11325:
Summary: SQL: Single place to start missing caches
(H2Utils.checkAndStartNotStartedCache)
Key: IGNITE-11325
URL: https://issues.apache.org/jira/browse/IGNITE-11325
Project: Ignite
Issue Type: Task
Components: sql
Reporter: Vladimir Ozerov
Fix For: 2.8
We need to start missing caches for the given SELECT/DML statement because we
need affinity info during query planning which is only available for started
caches.
We need to do the following:
# Move the method {{H2Utils.checkAndStartNotStartedCache}} to some common
place, e.g. parser, so that it has one and only one usage all over the code base
# Make sure that this method doesn't produce multiple network hops: missing
caches should be started in a single request if possible.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: Python examples are missing in Ignite 2.7
Dmitry, Thanks for looking into this. I think that something went wrong with our release procedure and we forgot to include the "examples" folder in Ignite binary package. Sergey K. is checking the release procedures. - Denis On Tue, Feb 12, 2019 at 7:28 PM Dmitry Melnichuk < dmitry.melnic...@nobitlost.com> wrote: > We just browse through the contents of the latest Ignite bundles [1]. > > Source bundle [2] contains the examples all right; they are in this > folder: > > /apache-ignite-2.7.0-src/modules/platforms/python/examples/ > > Binary bundle [3] do not contain examples. I'm not totally sure, but > the reasoning I gave earlier might apply to binary bundle too. > > Can anyone who's aware of the bundling procedure/scripts chime in, > please? > > [1] https://ignite.apache.org/download.cgi > > [2] > > http://mirrors.standaloneinstaller.com/apache//ignite/2.7.0/apache-ignite-2.7.0-src.zip > > [3] > > http://mirrors.standaloneinstaller.com/apache//ignite/2.7.0/apache-ignite-2.7.0-bin.zip > > On Wed, 2019-02-13 at 12:49 +1000, Dmitry Melnichuk wrote: > > Denis, > > > > If by “release procedure” you mean the contents of the PyPI package, > > then it is not a bug, but a deliberate decision, that was documented > > in > > README [1]: > > > > > Installation > > > > > > - for end user > > > > > > If you only want to use the pyignite module in your project, do: > > > > > > $ pip install pyignite > > > > > > -- for developer > > > > > > If you want to run tests, examples or build documentation, clone > > > the > > > whole repository… > > > > The reasoning: > > > > 1. The examples do not have much value by themselves. They are useful > > only in conjunction with the documentation. If we do not ship the > > documentation via PyPI, then we should not ship the examples either. > > > > 2. In production environment, the extra packaged stuff like examples > > will be just a waste of space. > > > > 3. Most Python libraries and frameworks I know of, e.g. Django or > > Scrapy, use the same approach: they have examples and test apps in > > the > > repository and reference them through their docs, but do not ship > > them > > via PyPI. > > > > [1] > > > https://github.com/apache/ignite/tree/master/modules/platforms/python#installation > > > > On Tue, 2019-02-12 at 16:23 -0800, Denis Magda wrote: > > > Igniters, > > > > > > Seems python examples were not added to the release bundle? > > > > https://apacheignite.readme.io/v2.7/docs/python-thin-client#section-running-an-example > > > > > > There is no "examples" folder for Python. Any flaws in the release > > > procedure? > > > > > > - > > > Denis > >
[jira] [Created] (IGNITE-11326) SQL: Common parsing logic
Vladimir Ozerov created IGNITE-11326: Summary: SQL: Common parsing logic Key: IGNITE-11326 URL: https://issues.apache.org/jira/browse/IGNITE-11326 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[MTCGA]: new failures in builds [3050467] needs to be handled
Hi Igniters, I've detected some new issue on TeamCity to be handled. You are more than welcomed to help. If your changes can lead to this failure(s): We're grateful that you were a volunteer to make the contribution to this project, but things change and you may no longer be able to finalize your contribution. Could you respond to this email and indicate if you wish to continue and fix test failures or step down and some committer may revert you commit. *Recently contributed test failed in master near.IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-4005992156292294495&branch=%3Cdefault%3E&tab=testDetails No changes in the build - Here's a reminder of what contributors were agreed to do https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute - Should you have any questions please contact dev@ignite.apache.org Best Regards, Apache Ignite TeamCity Bot https://github.com/apache/ignite-teamcity-bot Notification generated at 01:36:20 15-02-2019
[jira] [Created] (IGNITE-11327) Console error with progress line component
Alexander Kalinin created IGNITE-11327: -- Summary: Console error with progress line component Key: IGNITE-11327 URL: https://issues.apache.org/jira/browse/IGNITE-11327 Project: Ignite Issue Type: Bug Reporter: Alexander Kalinin Assignee: Alexander Kalinin -- This message was sent by Atlassian JIRA (v7.6.3#76005)
