Re: DiscoverySpi#setDataExchange returns concrete implementation

2017-05-28 Thread Николай Ижиков 
Hello. Here is pull request for this issue:

https://github.com/apache/ignite/pull/2022

2017-05-26 13:16 GMT+03:00 Yakov Zhdanov :

> Hi Nick! Good catch. Please go ahead and submit a patch.
>
> --Yakov
>
> 2017-05-26 13:09 GMT+03:00 Николай Ижиков :
>
> > Hello, guys.
> >
> > public interface DiscoverySpi extends IgniteSpi {
> > 
> > TcpDiscoverySpi setDataExchange(DiscoverySpiDataExchange var1);
> >
> > TcpDiscoverySpi setMetricsProvider(DiscoveryMetricsProvider var1);
> > ...
> > }
> >
> > Two methods of DiscoverySpi returns concrete implementation.
> > I think we should return interface, not implementation from this methods
> > Or why we need an interface?
> >
> > I can provide simple patch to fix this issue.
> >
> > --
> > Nikolay Izhikov
> > nizhikov@gmail.com
> >
>



-- 
Nikolay Izhikov
nizhikov@gmail.com

[GitHub] ignite pull request #2022: ignite-5321 DiscoverySpi methods return interface...

2017-05-28 Thread nizhikov 
GitHub user nizhikov opened a pull request:

https://github.com/apache/ignite/pull/2022

ignite-5321  DiscoverySpi methods return interface not implementation



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/nizhikov/ignite ignite-5321

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/2022.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2022


commit 001091503c681e7b979ab7b1ad0223cdec08397f
Author: Ижиков Николай Владимирович 

Date:   2017-05-28T16:22:16Z

ignite-5321 make DiscovertySpi methods return interface not implementation




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (IGNITE-5321) DiscoverySpi#setDataExchange returns concrete implementation

2017-05-28 Thread Nikolay Izhikov (JIRA) 
Nikolay Izhikov created IGNITE-5321:
---

 Summary: DiscoverySpi#setDataExchange returns concrete 
implementation
 Key: IGNITE-5321
 URL: https://issues.apache.org/jira/browse/IGNITE-5321
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.0
Reporter: Nikolay Izhikov
Assignee: Nikolay Izhikov
Priority: Trivial
 Fix For: 2.1


Two method of DiscoverySpi interface returns concrete implementation instead of 
interface.

{code:java}
public interface DiscoverySpi extends IgniteSpi {

TcpDiscoverySpi setDataExchange(DiscoverySpiDataExchange var1);

TcpDiscoverySpi setMetricsProvider(DiscoveryMetricsProvider var1);
...
}
{code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] ignite pull request #2021: IGNITE-5313

2017-05-28 Thread devozerov 
Github user devozerov closed the pull request at:

https://github.com/apache/ignite/pull/2021


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] ignite pull request #1954: ignite-gg-12199 added new variable CLEAN_WORK_DIR...

2017-05-28 Thread oleg-ostanin 
Github user oleg-ostanin closed the pull request at:

https://github.com/apache/ignite/pull/1954


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (IGNITE-5320) Add well-known SQL schema where caches will "live" by default

2017-05-28 Thread Vladimir Ozerov (JIRA) 
Vladimir Ozerov created IGNITE-5320:
---

 Summary: Add well-known SQL schema where caches will "live" by 
default
 Key: IGNITE-5320
 URL: https://issues.apache.org/jira/browse/IGNITE-5320
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Vladimir Ozerov
 Fix For: 2.1


Considerations:
1) Schema is always present and is never dropped
2) If {{CacheConfiguration.sqlSchema}} is not specified explicitly, cache 
should reside in default schema.
3) There should be a flag on cache configuration to allow fallback to previous 
behavior, when cache existed in separate schema equal to it's name.
4) CREATE TABLE can only create objects in default schema. Throw exception 
otherwise. That is, this is OK:
{code}
CREATE TABLE "default_schema".MyTable ...
{code}

And this is not:
{code}
CREATE TABLE "non_default_schema".MyTable ...
{code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-5319) Fix schema handling in v1 and v2 drivers

2017-05-28 Thread Vladimir Ozerov (JIRA) 
Vladimir Ozerov created IGNITE-5319:
---

 Summary: Fix schema handling in v1 and v2 drivers
 Key: IGNITE-5319
 URL: https://issues.apache.org/jira/browse/IGNITE-5319
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Vladimir Ozerov
 Fix For: 2.1


Currently both drivers behave as follows: when schema is changed, it is 
converted to cache name automatically. This is wrong. We should do the 
following:
1) Decouple schema name from cache name. Schema name should be separate field. 
No conversion.
2) When JDBC driver is connected, schema is set to the schema target cache 
belongs to
3) Cache name cannot be changed
4) Cache name is always passed to all tasks as before
5) Schema name is added to these tasks and propagated to respective 
{{SqlFieldsRequest}}. 
6) When done, {{H2Schema.cacheName}} and all it's usages could finally be 
removed.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-5318) Check if cache name should be removed from QueryTypeIdKey and QueryTypeNameKey classes

2017-05-28 Thread Vladimir Ozerov (JIRA) 
Vladimir Ozerov created IGNITE-5318:
---

 Summary: Check if cache name should be removed from QueryTypeIdKey 
and QueryTypeNameKey classes
 Key: IGNITE-5318
 URL: https://issues.apache.org/jira/browse/IGNITE-5318
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
 Fix For: 2.1


As a part of IGNITE-5054 refactoring, probably we should remove {{cacheName}} 
field from {{QueryTypeIdKey}} and {{QueryTypeNameKey}} classes. 

This is not necessarily so, because many-to-one mapping from type to cache is 
retained. So chances that this is a "Won't fix" ticket. Need to investigate.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-5317) Remove strict dependency on concrete cache from SQL execute methods

2017-05-28 Thread Vladimir Ozerov (JIRA) 
Vladimir Ozerov created IGNITE-5317:
---

 Summary: Remove strict dependency on concrete cache from SQL 
execute methods
 Key: IGNITE-5317
 URL: https://issues.apache.org/jira/browse/IGNITE-5317
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
 Fix For: 2.1


With all recent refactorings in place it should be fairly easy to do so.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-5316) Rework ODBC to schema-based approach

2017-05-28 Thread Vladimir Ozerov (JIRA) 
Vladimir Ozerov created IGNITE-5316:
---

 Summary: Rework ODBC to schema-based approach
 Key: IGNITE-5316
 URL: https://issues.apache.org/jira/browse/IGNITE-5316
 Project: Ignite
  Issue Type: Task
  Components: odbc, sql
Reporter: Vladimir Ozerov
Assignee: Igor Sapego
 Fix For: 2.1


Currently we pass cache name in ODBC requests and require it in connection 
string. Let's rework it to more generic "schema name".



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)