Re: ALTER TABLE command support

[Vladimir Ozerov]

Alex,

There are several complex things here:

1) DROP TABLE will require modification of data. Effectively, we have to
rebuild all binary objects in our cache. And the key question - how to make
this process efficient. Without it the following will fail:

INSERT INTO Person(id, salary) VALUES (1, 10_000);
ALTER TABLE Person DROP COLUMN salary;
ALTER TABLE Person ADD COLUMN salary;
SELECT salary FROM Person WHERE id = 1 // Must be NULL, but will be 10_000

2) DROP COLUMN must take in count indexes on the column (if any)

3) ALTER TABLE might IgniteCache.put() interfere with IgniteCache.put() in
subtle ways. E.g.:
INSERT INTO Person(id, salary) VALUES (1, 10_000);
ALTER TABLE Person DROP COLUMN salary;
IgniteCache.put(1, Builder["salary"=10_000]); // Should we allow or fail
this?

4) We have to rework DML as well. Otherwise current processors will work
incorrectly. Consider we have two threads T1 and T2:
T1: INSERT INTO Person(id, salary) VALUES (1, 10_000);
T1: Prepared entry processor
T2: ALTER TABLE Person DROP COLUMN salary
T1: Sent entry processor which completed successfully
T2: ALTER TABLE Person ADD COLUMN salary;
T2: SELECT salary FROM Person WHERE id = 1 // Must be NULL, but will be
10_000

Probably we will have to maintain a kind of schema versions or so here.

5) Last, but not least - design of this feature must take in count upcoming
MVCC, as their designs might be interrelated.

Vladimir.

On Thu, Jun 1, 2017 at 3:57 AM, Alexander Paschenko <
alexander.a.pasche...@gmail.com> wrote:

> Hi guys,
>
> To my knowledge, our binary format is currently resilient to
> adding/removing fields of individual objects while having those
> objects logically belonging to the same value type - thanks to all
> efforts with binary resolvers and stable field sorting. Thus, ALTER
> TABLE implemented as suggested (descriptors manipulation) indeed will
> not need actual data modification, amirite?
>
> That said, in my view at a first glance the task boils down to following:
>
> 1. Make type descriptors and table descriptors mutable in principle
> 2. Add Ignite ALTER TABLE command (at first approach let's limit
> ourselves with columns add/remove)
> 3. Implement its propagation and distributed execution (CREATE INDEX
> style - this mechanism of distributed schema changes has already been
> implemented by Vlad)
>
> 4. On local stage of distributed execution:
>
> 4.1. Issue on local H2 instance combination of DROP TABLE and then
> CREATE TABLE with new columns list.
> This is a lot like what H2 does when you ask it to ALTER TABLE, but H2
> actually also does data copying via SELECT which we don't need to do
> as far as I can see due to binary format resiliency I wrote above -
> our combination of local CREATE and DROP will modify local H2 metadata
> to look the way we ultimately need.
>
> 4.2. After we're finished with H2 metadata, we're safe to modify type
> and table descriptors.
>
> Of course some amount of additional work will be needed to make sure
> that such operations are mutually exclusive with cache gets/puts, or
> index creation, or cache creation (also implies manipulations with
> type descriptors and may also cause a CREATE TABLE in its own right).
> But still approach in general could be as described above.
>
> I also have some ideas about support for constraints which is in fact
> is also concerned with descriptors mutation, but I believe this is not
> the topic of this conversation.
>
> Thoughts?
>
> – Alex
>
> 2017-05-31 23:36 GMT+03:00 Denis Magda :
> > Agree. The gradual approach is the way to go for us.
> >
> > —
> > Denis
> >
> >> On May 31, 2017, at 1:20 PM, Dmitriy Setrakyan 
> wrote:
> >>
> >> I think a fully functional ALTER TABLE command may be hard to
> implement, as
> >> it includes changes of columns, types, constraints, etc... We should
> take a
> >> gradual approach here and implement this command by phases.
> >>
> >> I would propose that in the first phase we simply add the capability to
> add
> >> and remove columns to a table. This way, given that we already support
> >> CREATE INDEX command, the new column can be immediately indexed within
> the
> >> cluster and used for query execution.
> >>
> >> Does this sound like a plan?
> >>
> >> D.
> >>
> >> On Wed, May 31, 2017 at 11:52 AM, Denis Magda 
> wrote:
> >>
> >>> Sergi, Vovan, Alexander P.,
> >>>
> >>> It’s great that we added CREATE/DROP index commands support to Ignite.
> As
> >>> the next step, I think we need to move forward and plan to add ALTER
> TABLE
> >>> command to the list.
> >>>
> >>> The reason we should have this command is simple. If a user adds a new
> >>> field to Person class (while the cluster is up and running) then there
> >>> should be a way to access the field from SQL and index it later if
> needed.
> >>> Presently, this is not supported.
> >>>
> >>> What will be our efforts to support this?
> >>>
> >>> —
> >>> Denis
> >
>

[jira] [Created] (IGNITE-5367) Web console: Sql page fixes.

[Vasiliy Sisko (JIRA)]

Vasiliy Sisko created IGNITE-5367:
-

 Summary: Web console: Sql page fixes.
 Key: IGNITE-5367
 URL: https://issues.apache.org/jira/browse/IGNITE-5367
 Project: Ignite
  Issue Type: Bug
  Components: wizards
Affects Versions: 2.0
Reporter: Vasiliy Sisko
Assignee: Andrey Novikov
 Fix For: 2.1


# Not work refresh rage after explain query.
# Next page and (explain ?) buttons should be locked when query in progress.



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

[jira] [Created] (IGNITE-5366) Web Console: user notifications

[Ilya Borisov (JIRA)]

Ilya Borisov created IGNITE-5366:


 Summary: Web Console: user notifications
 Key: IGNITE-5366
 URL: https://issues.apache.org/jira/browse/IGNITE-5366
 Project: Ignite
  Issue Type: Task
  Components: wizards
Reporter: Ilya Borisov
Assignee: Andrey Novikov


Web console needs a way to notify all users, for example about upcoming version 
updates.

What to do:
1. Add a way for admin to manage notifications.
2. Display notifications in app header in style similar to "assummed identity" 
notification.



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

[GitHub] ignite pull request #2054: IGNITE-5328 Added CREATE TABLE params

[alexpaschenko]

GitHub user alexpaschenko opened a pull request:

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

IGNITE-5328 Added CREATE TABLE params



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

$ git pull https://github.com/gridgain/apache-ignite ignite-5328

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

https://github.com/apache/ignite/pull/2054.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 #2054


commit 3ad4fa125cad7ff1ae782f17d7a32c5e3ca5ad9a
Author: Alexander Paschenko 
Date:   2017-06-01T02:09:44Z

IGNITE-5328 Added CREATE TABLE params for backups number and atomicity mode.




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

Re: ALTER TABLE command support

[Alexander Paschenko]

Hi guys,

To my knowledge, our binary format is currently resilient to
adding/removing fields of individual objects while having those
objects logically belonging to the same value type - thanks to all
efforts with binary resolvers and stable field sorting. Thus, ALTER
TABLE implemented as suggested (descriptors manipulation) indeed will
not need actual data modification, amirite?

That said, in my view at a first glance the task boils down to following:

1. Make type descriptors and table descriptors mutable in principle
2. Add Ignite ALTER TABLE command (at first approach let's limit
ourselves with columns add/remove)
3. Implement its propagation and distributed execution (CREATE INDEX
style - this mechanism of distributed schema changes has already been
implemented by Vlad)

4. On local stage of distributed execution:

4.1. Issue on local H2 instance combination of DROP TABLE and then
CREATE TABLE with new columns list.
This is a lot like what H2 does when you ask it to ALTER TABLE, but H2
actually also does data copying via SELECT which we don't need to do
as far as I can see due to binary format resiliency I wrote above -
our combination of local CREATE and DROP will modify local H2 metadata
to look the way we ultimately need.

4.2. After we're finished with H2 metadata, we're safe to modify type
and table descriptors.

Of course some amount of additional work will be needed to make sure
that such operations are mutually exclusive with cache gets/puts, or
index creation, or cache creation (also implies manipulations with
type descriptors and may also cause a CREATE TABLE in its own right).
But still approach in general could be as described above.

I also have some ideas about support for constraints which is in fact
is also concerned with descriptors mutation, but I believe this is not
the topic of this conversation.

Thoughts?

– Alex

2017-05-31 23:36 GMT+03:00 Denis Magda :
> Agree. The gradual approach is the way to go for us.
>
> —
> Denis
>
>> On May 31, 2017, at 1:20 PM, Dmitriy Setrakyan  wrote:
>>
>> I think a fully functional ALTER TABLE command may be hard to implement, as
>> it includes changes of columns, types, constraints, etc... We should take a
>> gradual approach here and implement this command by phases.
>>
>> I would propose that in the first phase we simply add the capability to add
>> and remove columns to a table. This way, given that we already support
>> CREATE INDEX command, the new column can be immediately indexed within the
>> cluster and used for query execution.
>>
>> Does this sound like a plan?
>>
>> D.
>>
>> On Wed, May 31, 2017 at 11:52 AM, Denis Magda  wrote:
>>
>>> Sergi, Vovan, Alexander P.,
>>>
>>> It’s great that we added CREATE/DROP index commands support to Ignite. As
>>> the next step, I think we need to move forward and plan to add ALTER TABLE
>>> command to the list.
>>>
>>> The reason we should have this command is simple. If a user adds a new
>>> field to Person class (while the cluster is up and running) then there
>>> should be a way to access the field from SQL and index it later if needed.
>>> Presently, this is not supported.
>>>
>>> What will be our efforts to support this?
>>>
>>> —
>>> Denis
>

WAL fsync mode to the public API

[Denis Magda]

Alex G., Igniters,

Why do we hide WAL fsync modes in the internals of FileWriteAheadLogManager?


private enum Mode {
NONE, LOG_ONLY,

/**
 * Write is performed periodically, initiated by background thread,
 * calls to {@link 
IgniteWriteAheadLogManager#fsync(org.apache.ignite.internal.pagemem.wal.WALPointer)}
 have no effect.
 * Using this mode will decrease persistence reliability for performance
 */
BACKGROUND, DEFAULT
}
Can we move it to the public PersistentStoreConfiguration?

—
Denis

Re: contention on DataStructure creation/removing

[Dmitriy Setrakyan]

Won't it be confusing from a user stand point to have multiple data
structures with the same name? Also, what is the performance impact of this
change?

D.

On Wed, May 31, 2017 at 8:23 AM, Semyon Boikov  wrote:

> Hi Mikhail,
>
> As far as I remember for some reason we wanted to guarantee that all data
> structures have unique names. But now I don't see why this can be needed
> and it seems we do not need this data structures map at all, if nobody have
> objection I think you can implement suggested change.
>
> Thanks!
>
> On Wed, May 31, 2017 at 3:04 PM, Mikhail Cherkasov <
> mcherka...@gridgain.com>
> wrote:
>
> > Hi all,
> >
> > All DataStructures are stored in one Map which itself is stored in
> > utilityCache, this makes high contention on DS creation or removing, it
> > requires to acquire Map's lock and manipulation with the Map under the
> > lock. So all threads in cluster should wait for this lock to create or
> > remove DS.
> >
> > I don't see any reason to store all DS in one map,  we already have
> > utilityCache and can save DSs directly in utilityCache, to distinguish DS
> > with other objects in utilityCache I use composite key, the first part of
> > which is DATA_STRUCTURES_KEY, second one is DS's name, also DS type can
> be
> > added, this will allow us to create different DS with the same name.
> >
> > There is draft implementations, all DSs are stored with unique key in
> > utilityCache:
> > https://github.com/apache/ignite/pull/2046/files
> >
> > May be there's some reason to store all DS in one Map that I missed?
> > Any thoughts?
> >
> >
> > --
> > Thanks,
> > Mikhail.
> >
>

Re: Persistent Store Stabilization for release

[Dmitriy Setrakyan]

Thanks Denis. I also would like to encourage to post all the stabilization
updates for the donated branch here. This will help the community to get
familiar with the new code and functionality.

In addition, everyone in the community should feel free to peruse through
the code in this branch and ask any questions that may come up:

https://github.com/apache/ignite/tree/ignite-5267/modules/pds

D.


On Wed, May 31, 2017 at 2:37 PM, Denis Magda  wrote:

> Igniters,
>
> The Persistent Store donation was accepted by the community and now we
> should think of its readiness for a public release.
>
> I know that many of you are involved it the donation stabilization. Could
> you share the current status of the feature? How far is it from the
> releasable state?
>
> —
> Denis

Re: Summary of SQL changes in 2.1

[Dmitriy Setrakyan]

Vladmir,

Thanks for the detailed email. My comments are inline...

On Wed, May 31, 2017 at 11:21 AM, Vladimir Ozerov 
wrote:

> Folks,
>
> Let me summarize all recent changes to our SQL engine which are important
> from user perspective. Please think of them and let me know if you have any
> objection and thoughts on how to improve them.
>
> 1) Default "PUBLIC" schema added. It always exists and cannot be dropped.
> Many caches can reside in this schema as opposed to earlier versions, where
> every cache must be in separate schema.
>

Nice!


> 2) Caches are still created in separate schemas by default. We should not
> change this behavior, because it could break SQL queries of virtually all
> users.
>

We should document, however, that this behavior will change in 3.0. Also,
users should be able to specify that they wish to connect to the PUBLIC
schema explicitly.


> 3) "CREATE TABLE" creates a cache with special internal property
> "sql=true". Such cache cannot be destroyed through "Ignite.destroyCache".
> It can only be dropped through "DROP TABLE".The opposite is also holds:
> static and dynamic caches cannot be dropped through "DROP TABLE".
>

Agree.


>
> 4) "CREATE INDEX" and "DROP INDEX" can only be executed on "sql" caches.
>

Ouch! Many of current Ignite users wish to have this functionality enabled
for API-based caches. Any chance to lift this limitation?


>
> 5) There will be two predefined templates for "CREATE CACHE" command -
> "REPLICATED" and "PARTITIONED". They are always available on any node.
>
> 6) Additional parameters which could be passed to "CREATE TABLE":
> 6.1) "cacheTemplate" - name of cache template
> 6.2) "backups" - number of backups
> 6.3) "atomicityMode" - either "TRANSACTIONAL" or "ATOMIC"
> 6.4) "AFFINITY KEY" - if key field should be used for affinity.
>

What are the defaults?


>
> Example:
> CREATE TABLE Employee (
> pk_id BIGINT PRIMARY KEY,
> name VARCHAR(255),
> org_id BIGINT AFFINITY KEY
> ) WITH "cacheTemplate=PARTITIONED, backups=1, atomicityMode=TRANSACTIONAL"
>
> 7) Connetion string of new JDBC driver starts with "jdbc:ignite:thin://",
> and has only [host] as mandatory parameter.
>
> Example: "jdbc:ignite:thin://my_machine"
>

Why not have "thin" driver by default? Will users even notice?


>
> 8) New bean "SqlConfiguration" will be added to "IgniteConfiguration":
>
> class SqlConfiguration {
> SqlListenerConfiguration listenerCfg; // Content of this class will be
> copied from OdbcConfiguration;
> long longQryWarnTimeout; // Moved from CacheConfiguration
>
> // Will hold more common SQL stuff such as metrics frequency,
> predefined schemas, etc. in future.
> }
>
> class SqlListenerConfiguration {
> String host; // Optional, bind to all interfaces if ommitted;
> int port; // Port
> // Other stuff copied from OdbcConfiguration
> }
>
> Example of configuration with explicitly enabled listener:
> new IgniteConfiguration().setSqlConfiguration(new
> SqlConfiguration().setListenerConfiuration(new
> SqlListenerConfiguration()));
>

Seems that there is one-to-one dependency between SqlConfiguration and
SqlListenerConfiguration. This looks a bit dirty. Why not just have
SqlConfiguration with all the properties?


>
> 9) SQL listener *will not be enabled by default* as it consumes resources
> and normally will be require only on small set of nodes.
>

Again, seems to be very odd. I would like SqlConfiguration to be enabled by
default, given that many users will now connect to Ignite using the JDBC or
ODBC drivers.


>
> 10) OdbcConfiguration will be deprecated in favor of
> SqlListenerConfiguration.
>

Again, let's just have one SqlConfiguration interface. I am OK with
deprecating the OdbcConfiguration, assuming that it will still work.



>
> Please share your thoughts.
>

Re: Persistent Distributed Store Metrics

[Dmitriy Setrakyan]

Denis, I do agree, the concept of virtual memory may work. I will start
another discussion thread on that.

We should extensively javadoc all these interfaces. The current one-liner
javadoc documentation is not enough.

Also, I would like to make a small correction to the MemoryMetrics
interface, see below...


On Wed, May 31, 2017 at 1:35 PM, Denis Magda  wrote:

> Guys,
> If to assume that the *page memory* is a sort of *virtual* memory that
> maps a page to RAM or disk then MemoryMetrics interface makes sense if we
> think of it as {Virtual}MemoryMetrics. It’s late to rename the interface
> but this design flaw can be handled with a proper documentation.
> At all, let’s gather all the page memory related metrics (both RAM and
> disk) in MemoryMetrics interface. Here is it’s final version:
> public interface MemoryMetrics {
> public String getName();
>
> public long getTotalAllocatedPages();


I think this method currently returns only the pages allocated in memory.
To behave correctly, it now should return the total pages allocated within
the virtual memory, which should be equal to the total pages on disk.


> public long getPagesOnDisk();
>

This method should be removed as it represents the same value as
"getTotalAllocatedPages()" method. Instead, we should add the following
method:

// Returns the number of pages allocated in physical off-heap memory.
getPhysicalMemoryPages();


>
> public long getDirtyPages();
>
> public float getAllocationRate();
>
> public float getEvictionRate();
>
> public float getPagesFillFactor();
>
> public double getPagesMissRate();
>
> public float getLargeEntriesPagesPercentage();
> }
> I would rename getAllocationRate and getEvitionRate to
> getPagesAllocationRate and getEvictionRates respectively but then we need
> to deprecate the existing methods which is not good.
>
> As for the persistence metrics related to WAL and checkpointing let’s
> store them here:
>
> public interface PersistentStoreMetrics {
> public double getWalLoggingRate();
>
> public int getWalArchiveSegments();
>
> public double getWalFsyncTime();
>
> public double getCheckpointingTime();
>
> public double getCheckpointingFsyncTime();
>
> public long getCheckpointingTotalPagesNumber();
>
> public long[] getCheckpointingPagesByTypeNumber();
>
> public long getCheckpointingCopiedOnWritePagesNumber();
> }
>
> Comments on the name of non released methods are welcomed.
>
> —
> Denis
>
> > On May 30, 2017, at 2:59 PM, Dmitriy Setrakyan 
> wrote:
> >
> > On Tue, May 30, 2017 at 2:46 PM, Denis Magda  wrote:
> >
> >> I don’t have any extra metrics in mind for now. All I want to say that
> >> presently the Store metrics interface aggregates WAL and checkpointing
> >> metrics and in the future we might add additional Store related metrics
> >> there (that has nothing to do with WAL). So, this is why
> IgniteWalMetrics
> >> doesn’t sound like a generic interface.
> >>
> >
> > I think it is getting more and more confusing. I, for instance, do not
> > understand where memory metrics end and storage begins, neither I think
> it
> > is important to separate memory policy related metrics from the WAL or
> > Checkpoint related metrics.
> >
> > How about we put them all together and have clear method names?
> >
> >
> >>
> >> —
> >> Denis
> >>
> >>> On May 30, 2017, at 2:39 PM, Dmitriy Setrakyan 
> >> wrote:
> >>>
> >>> On Tue, May 30, 2017 at 1:22 PM, Denis Magda 
> wrote:
> >>>
>  I’m afraid that in the future we might need to add non WAL related
> >> metrics
>  under this interface. This is why it might make sense to keep the name
>  generic.
> 
> >>>
> >>> Hm... I am not sure we are going to have any other components in
> addition
> >>> to WAL and Store here. What do you have in mind?
> >>
> >>
>
>

Re: ALTER TABLE command support

[Denis Magda]

Agree. The gradual approach is the way to go for us.

—
Denis

> On May 31, 2017, at 1:20 PM, Dmitriy Setrakyan  wrote:
> 
> I think a fully functional ALTER TABLE command may be hard to implement, as
> it includes changes of columns, types, constraints, etc... We should take a
> gradual approach here and implement this command by phases.
> 
> I would propose that in the first phase we simply add the capability to add
> and remove columns to a table. This way, given that we already support
> CREATE INDEX command, the new column can be immediately indexed within the
> cluster and used for query execution.
> 
> Does this sound like a plan?
> 
> D.
> 
> On Wed, May 31, 2017 at 11:52 AM, Denis Magda  wrote:
> 
>> Sergi, Vovan, Alexander P.,
>> 
>> It’s great that we added CREATE/DROP index commands support to Ignite. As
>> the next step, I think we need to move forward and plan to add ALTER TABLE
>> command to the list.
>> 
>> The reason we should have this command is simple. If a user adds a new
>> field to Person class (while the cluster is up and running) then there
>> should be a way to access the field from SQL and index it later if needed.
>> Presently, this is not supported.
>> 
>> What will be our efforts to support this?
>> 
>> —
>> Denis

Re: ALTER TABLE command support

[Dmitriy Setrakyan]

I think a fully functional ALTER TABLE command may be hard to implement, as
it includes changes of columns, types, constraints, etc... We should take a
gradual approach here and implement this command by phases.

I would propose that in the first phase we simply add the capability to add
and remove columns to a table. This way, given that we already support
CREATE INDEX command, the new column can be immediately indexed within the
cluster and used for query execution.

Does this sound like a plan?

D.

On Wed, May 31, 2017 at 11:52 AM, Denis Magda  wrote:

> Sergi, Vovan, Alexander P.,
>
> It’s great that we added CREATE/DROP index commands support to Ignite. As
> the next step, I think we need to move forward and plan to add ALTER TABLE
> command to the list.
>
> The reason we should have this command is simple. If a user adds a new
> field to Person class (while the cluster is up and running) then there
> should be a way to access the field from SQL and index it later if needed.
> Presently, this is not supported.
>
> What will be our efforts to support this?
>
> —
> Denis

Re: ALTER TABLE command support

[Sergey Kozlov]

Denis

There's a few key points how we plan to process ALTER operations (online,
locking mode).

Take a look [1]

[1]
https://dev.mysql.com/doc/refman/5.6/en/innodb-create-index-overview.html

On Wed, May 31, 2017 at 9:52 PM, Denis Magda  wrote:

> Sergi, Vovan, Alexander P.,
>
> It’s great that we added CREATE/DROP index commands support to Ignite. As
> the next step, I think we need to move forward and plan to add ALTER TABLE
> command to the list.
>
> The reason we should have this command is simple. If a user adds a new
> field to Person class (while the cluster is up and running) then there
> should be a way to access the field from SQL and index it later if needed.
> Presently, this is not supported.
>
> What will be our efforts to support this?
>
> —
> Denis




-- 
Sergey Kozlov
GridGain Systems
www.gridgain.com

ALTER TABLE command support

[Denis Magda]

Sergi, Vovan, Alexander P.,

It’s great that we added CREATE/DROP index commands support to Ignite. As the 
next step, I think we need to move forward and plan to add ALTER TABLE command 
to the list.

The reason we should have this command is simple. If a user adds a new field to 
Person class (while the cluster is up and running) then there should be a way 
to access the field from SQL and index it later if needed. Presently, this is 
not supported.

What will be our efforts to support this?

—
Denis

[GitHub] ignite pull request #1989: IGNITE-4724: SQL: corrected result type for AVG()

[asfgit]

Github user asfgit closed the pull request at:

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


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

nested SQL sub-queries with non-collocated joins

[Dmitriy Setrakyan]

Igniters (specifically Sergi),

It has come to my attention today that nested sub-select statements, when
used in combination with non-collocated joins do not work properly in
Ignite.

So a query like this, where A, B, and C are all stored in Partitioned
caches and are **not** collocated at all, will not work.


> *select * from A, B where a.id  = b.a_id and b.somefield in
> (select somefield from C where c.zipcode = ?)*


The main reason it is not supported right now is because, in the absence of
collocation, such query may create N^N complexity and it was decided that
it is best not supporting it at all.

However, I am not sure why N^N complexity is required. Why not support it
as follows?

   1. execute the nested subquery and store the result in a temporary
   Replicated table.
   2. execute the original query and use the temporary Replicated table
   instead of the sub-query.

Sergi, given that you are the author of the code, can you provide some
insight here?

Thanks,
D.

Summary of SQL changes in 2.1

[Vladimir Ozerov]

Folks,

Let me summarize all recent changes to our SQL engine which are important
from user perspective. Please think of them and let me know if you have any
objection and thoughts on how to improve them.

1) Default "PUBLIC" schema added. It always exists and cannot be dropped.
Many caches can reside in this schema as opposed to earlier versions, where
every cache must be in separate schema.

2) Caches are still created in separate schemas by default. We should not
change this behavior, because it could break SQL queries of virtually all
users.

3) "CREATE TABLE" creates a cache with special internal property
"sql=true". Such cache cannot be destroyed through "Ignite.destroyCache".
It can only be dropped through "DROP TABLE".The opposite is also holds:
static and dynamic caches cannot be dropped through "DROP TABLE".

4) "CREATE INDEX" and "DROP INDEX" can only be executed on "sql" caches.

5) There will be two predefined templates for "CREATE CACHE" command -
"REPLICATED" and "PARTITIONED". They are always available on any node.

6) Additional parameters which could be passed to "CREATE TABLE":
6.1) "cacheTemplate" - name of cache template
6.2) "backups" - number of backups
6.3) "atomicityMode" - either "TRANSACTIONAL" or "ATOMIC"
6.4) "AFFINITY KEY" - if key field should be used for affinity.

Example:
CREATE TABLE Employee (
pk_id BIGINT PRIMARY KEY,
name VARCHAR(255),
org_id BIGINT AFFINITY KEY
) WITH "cacheTemplate=PARTITIONED, backups=1, atomicityMode=TRANSACTIONAL"

7) Connetion string of new JDBC driver starts with "jdbc:ignite:thin://",
and has only [host] as mandatory parameter.

Example: "jdbc:ignite:thin://my_machine"

8) New bean "SqlConfiguration" will be added to "IgniteConfiguration":

class SqlConfiguration {
SqlListenerConfiguration listenerCfg; // Content of this class will be
copied from OdbcConfiguration;
long longQryWarnTimeout; // Moved from CacheConfiguration

// Will hold more common SQL stuff such as metrics frequency,
predefined schemas, etc. in future.
}

class SqlListenerConfiguration {
String host; // Optional, bind to all interfaces if ommitted;
int port; // Port
// Other stuff copied from OdbcConfiguration
}

Example of configuration with explicitly enabled listener:
new IgniteConfiguration().setSqlConfiguration(new
SqlConfiguration().setListenerConfiuration(new SqlListenerConfiguration()));

9) SQL listener *will not be enabled by default* as it consumes resources
and normally will be require only on small set of nodes.

10) OdbcConfiguration will be deprecated in favor of
SqlListenerConfiguration.

Please share your thoughts.

Re: Cache.getAll can return partially commited results. IGNITE-4809

[Alexey Goncharuk]

Aleksey,

Generally, this decision cannot be made on a single node because a
transaction may affect multiple nodes, and one node may have already
committed the transaction and the other - not. There is a dependant ticket
in the ticket you are currently working on which will cover all the caes.

Meanwhile, an easy way to verify reads is to start an optimistic
serializable read-only transaction and commit it after reads. A commit will
throw OptimisticException if you happen to read an inconsistent set of
values.

2017-05-31 19:57 GMT+03:00 ALEKSEY KUZNETSOV :

> one possible solution is to lock entry reading section while userCommit()
> method is executing.
>
> ср, 31 мая 2017 г., 16:52 ALEKSEY KUZNETSOV :
>
> > Hi, Igntrs!
> > When the first writer thread has commited values and cache entries are
> > getting updated with this new values, another thread is getting partially
> > assigned values through the
> >
> > cache.getAll(keys)
> >
> > should this method wait for all newly updated entries to finish , or
> > should it throw the exception?
> >
> > If it should wait for entries, what mechanism shall i implement? would
> > appreciate any examples
> > --
> >
> > *Best Regards,*
> >
> > *Kuznetsov Aleksey*
> >
> --
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*
>

[jira] [Created] (IGNITE-5365) Build release artifacts once and use them for all editions

[Anton Vinogradov (JIRA)]

Anton Vinogradov created IGNITE-5365:


 Summary: Build release artifacts once and use them for all editions
 Key: IGNITE-5365
 URL: https://issues.apache.org/jira/browse/IGNITE-5365
 Project: Ignite
  Issue Type: Task
Reporter: Anton Vinogradov
Assignee: Oleg Ostanin






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

Re: Cache.getAll can return partially commited results. IGNITE-4809

[ALEKSEY KUZNETSOV]

one possible solution is to lock entry reading section while userCommit()
method is executing.

ср, 31 мая 2017 г., 16:52 ALEKSEY KUZNETSOV :

> Hi, Igntrs!
> When the first writer thread has commited values and cache entries are
> getting updated with this new values, another thread is getting partially
> assigned values through the
>
> cache.getAll(keys)
>
> should this method wait for all newly updated entries to finish , or
> should it throw the exception?
>
> If it should wait for entries, what mechanism shall i implement? would
> appreciate any examples
> --
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*
>
-- 

*Best Regards,*

*Kuznetsov Aleksey*

[GitHub] ignite pull request #2053: IGNITE-5364 Remove contention on DataStructure cr...

[mcherkasov]

GitHub user mcherkasov opened a pull request:

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

IGNITE-5364 Remove contention on DataStructure creation or removing

All DSs are stored in one Map which itself is stored in utilityCache, this 
makes high contention on DS creation or removing, it requires lock on the key 
and manipulation with the Map under the lock. So all threads in cluster should 
wait for this lock to create or remove DS.

I don't see any reason to store all DS in one map, we already have 
utilityCache and can save DSs directly in utilityCache, to distinguish DS with 
other objects in utilityCache I use composite key, the first part of which is 
DATA_STRUCTURES_KEY, second one is DS's name, also DS type can be added, this 
will allow us to create different DS with the same name.

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

$ git pull https://github.com/gridgain/apache-ignite ignite-5364

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

https://github.com/apache/ignite/pull/2053.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 #2053


commit 1d2c6b9c97584cf7603aa08ee07e71940037f92f
Author: mcherkasov 
Date:   2017-05-31T16:17:52Z

Removed a Map with DataStructures. DataStructures are added directly to 
utilityCache.




---
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 #2052: IGNITE-3795: Added C++ cache query tests with CUR...

[isapego]

GitHub user isapego opened a pull request:

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

IGNITE-3795: Added C++ cache query tests with CURDATE()



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

$ git pull https://github.com/gridgain/apache-ignite ignite-3795

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

https://github.com/apache/ignite/pull/2052.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 #2052


commit 593e32e7333295962fb4f23169b9940955c3526f
Author: Igor Sapego 
Date:   2017-05-31T16:43:04Z

IGNITE-3795: Added tests with CURDATE()




---
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-5364) Remove contention on DS creation or removing

[Mikhail Cherkasov (JIRA)]

Mikhail Cherkasov created IGNITE-5364:
-

 Summary: Remove contention on DS creation or removing
 Key: IGNITE-5364
 URL: https://issues.apache.org/jira/browse/IGNITE-5364
 Project: Ignite
  Issue Type: Improvement
Reporter: Mikhail Cherkasov
Assignee: Mikhail Cherkasov
 Fix For: 2.1


All DSs are stored in one Map which itself is stored in utilityCache, this 
makes high contention on DS creation or removing, it requires lock on the key 
and manipulation with the Map under the lock. So all threads in cluster should 
wait for this lock to create or remove DS.



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

[jira] [Created] (IGNITE-5363) Exception in logs after starting cluster in inactive mode and subsequent activation

[Sergey Chugunov (JIRA)]

Sergey Chugunov created IGNITE-5363:
---

 Summary: Exception in logs after starting cluster in inactive mode 
and subsequent activation
 Key: IGNITE-5363
 URL: https://issues.apache.org/jira/browse/IGNITE-5363
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 2.1
Reporter: Sergey Chugunov


h2. Notes
A "no-op" test reproducing the issue is attached.

h2. Steps to reproduce
# Start cluster in inactive mode ({{IgniteConfiguration.setActiveOnStart}})
# Activate cluster from any server node ({{Ignite.active(true)}})

h2. Expected behavior
No exceptions in logs

h2. Actual behavior
The following exception is printed out in logs, although cluster looks working 
fine:
{code}
[18:00:42,159][ERROR][exchange-worker-#25%db.IgniteDbWholeClusterRestartSelfTest0%][GridCacheDatabaseSharedManager]
 Failed to register MBean for MemoryMetrics with name: 'sysMemPlc'
javax.management.InstanceAlreadyExistsException: 
org.apache:clsLdr=4e25154f,igniteInstanceName=db.IgniteDbWholeClusterRestartSelfTest0,group=MemoryMetrics,name=sysMemPlc
at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
at 
com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
at 
org.apache.ignite.internal.util.IgniteUtils.registerMBean(IgniteUtils.java:4539)
at 
org.apache.ignite.internal.processors.cache.database.IgniteCacheDatabaseSharedManager.registerMetricsMBean(IgniteCacheDatabaseSharedManager.java:148)
at 
org.apache.ignite.internal.processors.cache.database.IgniteCacheDatabaseSharedManager.registerMetricsMBeans(IgniteCacheDatabaseSharedManager.java:135)
at 
org.apache.ignite.internal.processors.cache.database.IgniteCacheDatabaseSharedManager.init(IgniteCacheDatabaseSharedManager.java:119)
at 
org.apache.ignite.internal.processors.cache.database.IgniteCacheDatabaseSharedManager.start0(IgniteCacheDatabaseSharedManager.java:102)
at 
org.apache.ignite.internal.processors.cache.database.GridCacheDatabaseSharedManager.initDataBase(GridCacheDatabaseSharedManager.java:400)
at 
org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.onActivate(GridClusterStateProcessor.java:453)
at 
org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.onChangeGlobalState(GridClusterStateProcessor.java:367)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onCacheChangeRequest(GridDhtPartitionsExchangeFuture.java:744)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:536)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1802)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:745)
{code}



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

[GitHub] ignite pull request #2037: IGNITE-5161: Implemented compute example for C++

[isapego]

Github user isapego closed the pull request at:

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


---
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 #2047: IGNITE-5154: Added RemoteFilter to C++ ContinuosQ...

[isapego]

Github user isapego closed the pull request at:

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


---
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 #2051: Ignite 1.9.3 Release

[ezhuravl]

GitHub user ezhuravl opened a pull request:

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

Ignite 1.9.3 Release



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

$ git pull https://github.com/gridgain/apache-ignite ignite-1.9.3

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

https://github.com/apache/ignite/pull/2051.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 #2051


commit 8c56e4516e55c7ed9c14779f0e77e00f055d9a81
Author: vozerov-gridgain 
Date:   2016-09-02T15:05:16Z

IGNITE-3827: Removed double marshalling of keys in 
DataStreamerImpl.addData(Map) method.

commit 4dc624fc9a8852f77f1fe7db4dc06a474b34c2eb
Author: vozerov-gridgain 
Date:   2016-09-02T15:23:09Z

IGNITE-3829: Optimized affinity key field name handling.

commit 7b0d2326ccc62afd5d162b056398f96d8d7c9100
Author: vozerov-gridgain 
Date:   2016-09-05T07:19:48Z

IGNITE-3829: Additional fix.

commit b8cb82de65a529040ea18b0dc03fa7109c69bb4a
Author: Vasiliy Sisko 
Date:   2016-12-29T07:48:45Z

IGNITE-4442 Implemented cache affinity configuration.

(cherry picked from commit f4a1e6c)

commit 71412cecd861119965a873520da96078f99c94e2
Author: Anton Vinogradov 
Date:   2016-12-30T10:41:34Z

IGNITE-4424 REPLICATED cache isn't synced across nodes

commit 852f03829c997883376245e3515e47822e9012eb
Author: Andrey Novikov 
Date:   2017-01-11T09:34:23Z

Merge branches 'ignite-1.7.5' and 'web-console-production' of 
https://github.com/gridgain/apache-ignite into web-console-production

commit fe424591161595de1151a29cf1cdeb50456c3e39
Author: Andrey V. Mashenkov 
Date:   2017-01-12T14:43:21Z

Minors

commit cf9f0a79da7540dc40c3ac860a94158e87e2d7ec
Author: Andrey V. Mashenkov 
Date:   2017-01-12T14:50:02Z

Minors

commit d3e2e0c5574f7677645e73e1fbafaee3563895f1
Author: Andrey Novikov 
Date:   2017-01-25T07:27:01Z

Merge branches 'ignite-1.7.6' and 'web-console-production' of 
https://github.com/gridgain/apache-ignite into web-console-production

commit 295f80d10da02692540435d46961a9c3cca99b3c
Author: Andrey Novikov 
Date:   2017-01-25T06:58:57Z

IGNITE-4520 Added credential request for authentication on proxy.

(cherry picked from commit ef04f35)

commit faa20530a707014ac34477cba8adaaa4b67de1bb
Author: Andrey Novikov 
Date:   2017-01-25T09:48:05Z

IGNITE-1596 Fixed version sort.

(cherry picked from commit 128ba07)

commit 1b3bbdb1758eb19c755dabcb5fe329529fa0f378
Author: Andrey Novikov 
Date:   2017-01-27T04:30:49Z

IGNITE-4622 Fixed generation in domain model for cache store.

(cherry picked from commit 43007d5)

commit a8355feef630a5c8c4edbe02224c8325dd5952d3
Author: Andrey Novikov 
Date:   2017-02-03T04:58:43Z

IGNITE-4610 Added more informative message.

(cherry picked from commit 9ff2a8f)

commit 94d8a6fc0a61bb3046e2ebd8b3cbffb8917c2b6a
Author: Andrey Novikov 
Date:   2017-02-08T04:43:22Z

IGNITE-4472 Added user activities in Web Console.

(cherry picked from commit 26ee9c2)

commit b571fd40f009709718bce0c969d47b62be06b8f6
Author: Andrey Novikov 
Date:   2017-02-08T10:05:08Z

IGNITE-4472 Added user activities in Web Console.

(cherry picked from commit 26ee9c2)

commit db48f545a83bb72cded77d8269fe4f8820e8380f
Author: Andrey Novikov 
Date:   2017-02-10T08:55:05Z

IGNITE-4678 Web Console: Implemented demo load as service.

(cherry picked from commit a600caf)

commit e4b54c985f256478ae2cae23b423d9b8e0842df8
Author: Andrey Novikov 
Date:   2017-02-13T02:48:50Z

Merge branch 'ignite-1.8.3' of https://github.com/gridgain/apache-ignite 
into web-console-production

commit 2d6735a20ac8009d1ac3f003da4fcd319271bd71
Author: Alexey Kuznetsov 
Date:   2017-02-09T09:44:41Z

IGNITE-4676 Fixed hang if closure executed nested internal task with 
continuation. Added test.

(cherry picked from commit e7a5307)

commit d307e2eced1fd10b007ee08c3dd113e7bb4f22ba
Author: Andrey Novikov 
Date:   2017-02-13T10:35:29Z

IGNITE-4687 Added pool to process REST request in Web Agent.

(cherry picked from commit 262a341)

commit 8874f99f44dc2edf08a525619edb49d5db70b938
Author: dkarachentsev 
Date:   2017-02-14T15:44:57Z

IGNITE-4641 - Refresh client attributes during reconnect

commit ca5956bedfc0c3bd18290c64b6a6c2e3f114a440
Author: Andrey Novikov 
Date:   2017-02-14T16:28:06Z

place for printing info about partition distribution

[Вадим Опольский]

Hello guys!

I want to discuss and suggest some format and place for pinting info about
partition distribution to log from issue
https://issues.apache.org/jira/browse/IGNITE-4756

What do you think about it ?

Issue is about RendezvousAffinityFunction and FairAffinityFunction classes.

Vadim

Re: contention on DataStructure creation/removing

[Semyon Boikov]

Hi Mikhail,

As far as I remember for some reason we wanted to guarantee that all data
structures have unique names. But now I don't see why this can be needed
and it seems we do not need this data structures map at all, if nobody have
objection I think you can implement suggested change.

Thanks!

On Wed, May 31, 2017 at 3:04 PM, Mikhail Cherkasov 
wrote:

> Hi all,
>
> All DataStructures are stored in one Map which itself is stored in
> utilityCache, this makes high contention on DS creation or removing, it
> requires to acquire Map's lock and manipulation with the Map under the
> lock. So all threads in cluster should wait for this lock to create or
> remove DS.
>
> I don't see any reason to store all DS in one map,  we already have
> utilityCache and can save DSs directly in utilityCache, to distinguish DS
> with other objects in utilityCache I use composite key, the first part of
> which is DATA_STRUCTURES_KEY, second one is DS's name, also DS type can be
> added, this will allow us to create different DS with the same name.
>
> There is draft implementations, all DSs are stored with unique key in
> utilityCache:
> https://github.com/apache/ignite/pull/2046/files
>
> May be there's some reason to store all DS in one Map that I missed?
> Any thoughts?
>
>
> --
> Thanks,
> Mikhail.
>

[GitHub] ignite pull request #2050: IGNITE-5255 JDBC Driver: support DML

[tledkov-gridgain]

GitHub user tledkov-gridgain opened a pull request:

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

IGNITE-5255 JDBC Driver: support DML



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

$ git pull https://github.com/gridgain/apache-ignite ignite-5255

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

https://github.com/apache/ignite/pull/2050.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 #2050


commit c7e215347e567f5c6c11954d932cfbb63743ec24
Author: tledkov-gridgain 
Date:   2017-05-04T14:59:38Z

IGNITE-5163 save the progress

commit b0023f87ab9f08063001bee77931ae9edc13487e
Author: tledkov-gridgain 
Date:   2017-05-05T12:03:08Z

IGNITE-5163 save the progress

commit fa9fee2a996f676f2a1c3371adaf0a35ce2810f7
Author: tledkov-gridgain 
Date:   2017-05-05T12:03:14Z

Merge branch '_master' into ignite-5163

commit dca4546b82547f1eef97e7bd1f3254914d3b5055
Author: tledkov-gridgain 
Date:   2017-05-05T12:06:04Z

Merge branch '_master' into ignite-5163

commit db57be2da1beddc91df301033386f2a97ec578f2
Author: tledkov-gridgain 
Date:   2017-05-05T12:11:29Z

IGNITE-5163: fix after merge

commit 4412b1b085c7f81426e4d11b139ad856f0b6bf2d
Author: tledkov-gridgain 
Date:   2017-05-05T12:33:10Z

IGNITE-5163: minor

commit d8d0a9b6309cd75b37ff50f18c22560a26c9c23b
Author: tledkov-gridgain 
Date:   2017-05-05T14:02:46Z

Merge branch 'master' into ignite-5163

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/odbc/SqlListenerProtocolVersion.java

commit 7f60086405d8160c5d24f9a5cd36f99e81fd8e4e
Author: tledkov-gridgain 
Date:   2017-05-05T14:54:15Z

IGNITE-5163: fix after merge

commit 461a6fe654db0e81f84c74649b5e88a703af80c9
Author: tledkov-gridgain 
Date:   2017-05-05T15:04:50Z

IGNITE-5163: add properties to handshake

commit abd3894dd3419bdc1a14f15893fc9737d1cd0761
Author: tledkov-gridgain 
Date:   2017-05-05T15:08:01Z

IGNITE-5163: minors

commit 7ddc2f7641f222a29dbc8caa5197f453db0d5981
Author: tledkov-gridgain 
Date:   2017-05-10T08:49:17Z

Merge branch '_master' into ignite-5163

commit 9bfe91d3a597083da921220650c3e417dbb0b5c6
Author: devozerov 
Date:   2017-05-10T09:59:22Z

Merge branch 'master' into ignite-5163

commit a303e25e5d1fe815e314d4fad2858d1d374487a8
Author: devozerov 
Date:   2017-05-10T10:24:00Z

Review.

commit 8b94095ab8ab8a70d7fc9ec20df52e0c19d5bd19
Author: devozerov 
Date:   2017-05-10T10:25:28Z

Merge remote-tracking branch 'upstream/ignite-5163' into ignite-5163

# Conflicts:
#   modules/core/src/main/java/org/apache/ignite/IgniteJdbcThinDriver.java
#   
modules/core/src/main/java/org/apache/ignite/internal/jdbc/thin/JdbcTcpIo.java

commit e8eb3f519dbd8a1bca3acf42bb8b8477afc385e4
Author: tledkov-gridgain 
Date:   2017-05-11T12:03:18Z

IGNITE-5163: fix review issues

commit 081f27794d76adbf61add720dd0b1f88a69b373e
Author: tledkov-gridgain 
Date:   2017-05-11T12:10:13Z

IGNITE-5163: minors

commit 0c045b61faa1791f7c4929f208bd0e83e3b581cb
Author: tledkov-gridgain 
Date:   2017-05-11T12:59:54Z

Merge branch '_master' into ignite-5163

commit d715f83068877c4532c9f0bcb008f2ab5e0571e1
Author: tledkov-gridgain 
Date:   2017-05-11T15:58:25Z

IGNITE-5176: save the progress

commit 9f1c6ac0c1223c550335387737b817ca491615c3
Author: tledkov-gridgain 
Date:   2017-05-12T11:57:08Z

IGNITE-5176: save the progress

commit 58417ef19844d625935b8d4ca7a3237cca7c72af
Author: tledkov-gridgain 
Date:   2017-05-12T12:44:44Z

Merge branch '_master' into ignite-5163

commit 80435c4344dea89a8f39fe4bfe6cc78174c2bede
Author: tledkov-gridgain 
Date:   2017-05-12T12:45:42Z

Merge branch '_master' into ignite-5176

commit 3e366385f336a385fd4c4818578626eeca73e38d
Author: tledkov-gridgain 
Date:   2017-05-12T13:15:58Z

IGNITE-5163: serialization refactoring

commit e4e38acc67f0d607ac08d8e53ecece2459d6a364
Author: tledkov-gridgain 
Date:   2017-05-12T13:16:33Z

Merge branch 'ignite-5163' into ignite-5176

commit 7b5a2987ac6128d341f8731544a754b11f93924b
Author: tledkov-gridgain 
Date:   2017-05-12T13:44:33Z

IGNITE-5176: save the progress

commit a1e67bfcdbbfb290b912174531569c965b029f36
Author: tledkov-gridgain 
Date:   2017-05-12T13:47:39Z

IGNITE-5163: serialization 

[jira] [Created] (IGNITE-5362) Improve test coverage of SQL schema-related changes

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-5362:
---

 Summary: Improve test coverage of SQL schema-related changes
 Key: IGNITE-5362
 URL: https://issues.apache.org/jira/browse/IGNITE-5362
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Vladimir Ozerov
 Fix For: 2.1


Use {{SqlPublicSchemaSelfTest}} as a base. What to test:
1) Type name conflicts
2) Index and table name conflicts
3) Cleanup on cache destroy 
4) Multinode tests
5) Different cache modes
6) Client and server nodes



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

[jira] [Created] (IGNITE-5361) Query for string field represented as CHAR SQL type in underlying database doesn't retrieve entires that were loaded with CacheJdbcPojoStore

[Andrey Gura (JIRA)]

Andrey Gura created IGNITE-5361:
---

 Summary: Query for string field represented as CHAR SQL type in 
underlying database doesn't retrieve entires that were loaded with 
CacheJdbcPojoStore
 Key: IGNITE-5361
 URL: https://issues.apache.org/jira/browse/IGNITE-5361
 Project: Ignite
  Issue Type: Bug
Affects Versions: 1.7
Reporter: Andrey Gura


Use case:

There is database where primary key has type {{CHAR(N)}} (not {{VARCHAR}}). In 
this case string that have length less than {{N}} will be spaces padded.

Data has loaded into Ignite cache using {{CacheJdbcPojoStore}}. As result 
string field contains trailing spaces. The following SQL query wont retrieve 
expected value in case when string parameter doesn't contain trailing spaces: 

{noformat}
select * from MyTable where id = 'some_value_without_trailing spaces'
{noformat}

Moreover, if {{readThrough}} is enabled, and {{cache.get()}} operation will be 
invoked, and string identifier in key contains the same value without trailing 
spaces the entry will be loaded from underlying database. As result cache will 
contain two values with differents keys (one of them with trailing spaces while 
other without trailing spaces).

Looks like usability bug.



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

[GitHub] ignite pull request #2049: IGNITE-5243

[alexpaschenko]

GitHub user alexpaschenko opened a pull request:

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

IGNITE-5243



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

$ git pull https://github.com/gridgain/apache-ignite ignite-5243

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

https://github.com/apache/ignite/pull/2049.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 #2049


commit aa48bab0848e776754638bce07097b16006cd548
Author: Alexander Paschenko 
Date:   2017-04-21T16:05:06Z

IGNITE-5052 CREATE TABLE first steps

commit 7f04ca5811e4680f75996b30a73c7987eec19a25
Author: Alexander Paschenko 
Date:   2017-04-24T17:20:22Z

IGNITE-5052 CREATE TABLE parsing contd

commit 9ba38c926420b4f6d822885cb595c69de8a518c1
Author: Alexander Paschenko 
Date:   2017-04-25T14:38:57Z

Merge remote-tracking branch 'apache/ignite-2.0' into ignite-5052

commit d6cdb6ab208e24c65e2bc5d6ea8c88344b3725d6
Author: Alexander Paschenko 
Date:   2017-04-25T15:11:37Z

IGNITE-5052 CREATE TABLE parsing contd

commit 0be9b0877031bafda674949b13db6b3492bd8fe8
Author: Alexander Paschenko 
Date:   2017-04-26T08:14:29Z

IGNITE-5052 Dynamic local CREATE TABLE

commit 6569d53e91ef698c7955939cbf3681ebaf68a6c2
Author: Alexander Paschenko 
Date:   2017-04-26T18:55:23Z

IGNITE-5052 CREATE/DROP TABLE + few tests

commit a7e409b5cea3513e9dcdc242fbde057a99ad84a4
Author: Alexander Paschenko 
Date:   2017-04-27T18:01:17Z

IGNITE-5052 GridSqlCreateTable.toSql

commit 7d3325e1809fe33cb183ef8de3559ee0b2e40048
Author: Alexander Paschenko 
Date:   2017-04-28T11:46:42Z

Merge remote-tracking branch 'apache/ignite-2.0' into ignite-5052

commit b740701d61f7728c78b117bb5edbc60f0cba46e9
Author: Alexander Paschenko 
Date:   2017-04-28T11:51:51Z

Post merge fix

commit e650908cbf3358de731c7da606b22606834dfa85
Author: devozerov 
Date:   2017-05-05T11:02:43Z

Merge branch 'master' into ignite-5052

commit afda2220361158434e0b2f86f6d8f21c0342babf
Author: Alexander Paschenko 
Date:   2017-05-10T10:54:50Z

Merge branch 'master' into ignite-5052

commit dc5f68b9224adcaf1bdde2a6e2606d33a5549993
Author: Alexander Paschenko 
Date:   2017-05-10T19:03:01Z

IGNITE-5052 Review fixes

commit 888eb168685f6e63541ef7c3b096e32cae54fd4d
Author: Alexander Paschenko 
Date:   2017-05-11T11:31:15Z

IGNITE-5052 Review fixes - contd

commit 9a26a678f554c550739d06fef6ab371afb4c46f6
Author: Alexander Paschenko 
Date:   2017-05-11T11:32:51Z

Merge remote-tracking branch 'apache/master' into ignite-5052

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/query/GridQueryIndexing.java

commit 7f377c4de364907e27d143f1ae8263dcd3125db0
Author: devozerov 
Date:   2017-05-16T08:07:22Z

Merge branch 'master' into ignite-5052

commit 41e2f64cad6dfe33c28266281229b86b413e86a2
Author: devozerov 
Date:   2017-05-16T08:56:40Z

Minors.

commit 588093fd8db6ef8aae8b6e53f289a100dbe26853
Author: Alexander Paschenko 
Date:   2017-05-16T16:16:44Z

IGNITE-5052 Review fixes.

commit e2bb7bd2ee1f4d8419f8f918d69b50f68d0c0efc
Author: Alexander Paschenko 
Date:   2017-05-16T16:16:53Z

Merge branch 'master' into ignite-5052

commit e88a287b9a6b1f1372972b5d8223d3405152fcca
Author: Alexander Paschenko 
Date:   2017-05-17T09:04:36Z

Merge branch 'master' into ignite-5052

commit eef106ff955cd24884d60536bcc97797ec613b6c
Author: Alexander Paschenko 
Date:   2017-05-17T16:09:55Z

IGNITE-5052 Review fixes.

commit f9fa7e7ee52ac9ea3510be10d865d1ecb77c3365
Author: Alexander Paschenko 
Date:   2017-05-18T10:12:20Z

Merge branch 'master' into ignite-5052

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/CacheAffinitySharedManager.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/DynamicCacheDescriptor.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCachePartitionExchangeManager.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheProcessor.java
#   

Contributor access

[lexa]

Dear Ignite community, 

Can you please grant me (lexa) contributor access, so that I can 
assign Ignite Jira issues to myself ? 

Best Regards
Aleksey Chetaev.



--
View this message in context: 
http://apache-ignite-developers.2346864.n4.nabble.com/Contributor-access-tp18242.html
Sent from the Apache Ignite Developers mailing list archive at Nabble.com.

Cache.getAll can return partially commited results. IGNITE-4809

[ALEKSEY KUZNETSOV]

Hi, Igntrs!
When the first writer thread has commited values and cache entries are
getting updated with this new values, another thread is getting partially
assigned values through the

cache.getAll(keys)

should this method wait for all newly updated entries to finish , or should
it throw the exception?

If it should wait for entries, what mechanism shall i implement? would
appreciate any examples
-- 

*Best Regards,*

*Kuznetsov Aleksey*

[GitHub] ignite pull request #2048: IGNITE-5358 .NET: Fix nullable enum field handlin...

[ptupitsyn]

GitHub user ptupitsyn opened a pull request:

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

IGNITE-5358 .NET: Fix nullable enum field handling in binary objects



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

$ git pull https://github.com/ptupitsyn/ignite ignite-5358

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

https://github.com/apache/ignite/pull/2048.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 #2048


commit adf8d59c8fd979586b68c3aac1e7fe0511e84de4
Author: Pavel Tupitsyn 
Date:   2017-05-31T12:50:34Z

IGNITE-5358 .NET: Nullable enum field in binary object causes type cast 
exception

commit d4d0e4eed9dea9fa1cc930be1f7d90064a003e22
Author: Pavel Tupitsyn 
Date:   2017-05-31T13:00:53Z

wip

commit a7d5ec1936cab7c1f9beae23008434972719a799
Author: Pavel Tupitsyn 
Date:   2017-05-31T13:05:28Z

wip

commit 64b0e644bba8b3e1ee3b4f701b227ac796f8574f
Author: Pavel Tupitsyn 
Date:   2017-05-31T13:07:32Z

wip

commit 1d055602395546b49995f418c997c25d295f1b35
Author: Pavel Tupitsyn 
Date:   2017-05-31T13:10:01Z

wip

commit 56bcf72deeb6b65dec8220129ecebef5cb6e61d0
Author: Pavel Tupitsyn 
Date:   2017-05-31T13:13:38Z

wip reproducer done

commit 09f63b9409d98a9f5b80abb52fd771a9d7c1d44a
Author: Pavel Tupitsyn 
Date:   2017-05-31T13:16:27Z

wip

commit 1c9337f2cde926104b8357784cfdbddca03c6336
Author: Pavel Tupitsyn 
Date:   2017-05-31T13:21:17Z

wip

commit 4b9c9a60b4f752788d079112ecbb5ef626423059
Author: Pavel Tupitsyn 
Date:   2017-05-31T13:46:11Z

Fix the bug.




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

Re: Grant contributors access

[Yakov Zhdanov]

Done! Feel free to proceed!

--Yakov

2017-05-31 12:07 GMT+03:00 Алексей Четаев :

> Dear Ignite community,
>
> Can you please grant me (lexa) contributor access, so that I can
> assign Ignite Jira issues to myself ?
>
> Best Regards
> Aleksey Chetaev.
>

[GitHub] ignite pull request #2038: IGNITE-5337: Renamed C++ example executables for ...

[isapego]

Github user isapego closed the pull request at:

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


---
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-5360) Validate SQL configuration state from discovery thread

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-5360:
---

 Summary: Validate SQL configuration state from discovery thread
 Key: IGNITE-5360
 URL: https://issues.apache.org/jira/browse/IGNITE-5360
 Project: Ignite
  Issue Type: Task
  Components: cache, sql
Reporter: Vladimir Ozerov
 Fix For: 2.1


If started cache belongs to shared schema, we may receive exception due to 
duplicate objects (tables, indexes) in exchange thread, thus causing a hang.

Need to implement additional validation in discovery thread when it is safe to 
fail.

See {{SqlPublicSchemaSelfTest#_testTypeConflictInPublicSchema}} as an example 
of failing test.



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

Grant contributors access

[Алексей Четаев]

Dear Ignite community,

Can you please grant me (lexa) contributor access, so that I can
assign Ignite Jira issues to myself ?

Best Regards
Aleksey Chetaev.

[jira] [Created] (IGNITE-5359) SQL subquery with aggregates return wrong results.

[Andrew Mashenkov (JIRA)]

Andrew Mashenkov created IGNITE-5359:


 Summary: SQL subquery with aggregates return wrong results.
 Key: IGNITE-5359
 URL: https://issues.apache.org/jira/browse/IGNITE-5359
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.0
Reporter: Andrew Mashenkov
Priority: Blocker
 Fix For: 2.1


PFA repro attached.



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

[jira] [Created] (IGNITE-5358) .NET: Nullable enum field in binary object causes type cast exception

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-5358:
--

 Summary: .NET: Nullable enum field in binary object causes type 
cast exception
 Key: IGNITE-5358
 URL: https://issues.apache.org/jira/browse/IGNITE-5358
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Affects Versions: 2.0
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
Priority: Critical
 Fix For: 2.1


Reproducer:

{code}
enum TestEnum
{
TestValue1,
TestValue2
};

class TestClass
{
public string Name { get; }
public TestEnum? EnumValue { get; }

public TestClass(string name, TestEnum? enumValue)
{
Name = name;
EnumValue = enumValue;
}
}
...

cache.Put("TestElem1", new TestClass("TestElem1", TestEnum.TestValue1));
cache.Get("TestElem1");  // exception
{code}

Exception:
{code}
No coercion operator is defined between types 
'Apache.Ignite.Core.Impl.Binary.BinaryEnum' and 
'System.Nullable`1[UserQuery+TestEnum]'. 
{code}



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

Re: contention on DataStructure creation/removing

[Anton Vinogradov]

Mikhail,

Seems,
This can solve "slow reentrantLock" issue, at least at creation stage.

On Wed, May 31, 2017 at 3:04 PM, Mikhail Cherkasov 
wrote:

> Hi all,
>
> All DataStructures are stored in one Map which itself is stored in
> utilityCache, this makes high contention on DS creation or removing, it
> requires to acquire Map's lock and manipulation with the Map under the
> lock. So all threads in cluster should wait for this lock to create or
> remove DS.
>
> I don't see any reason to store all DS in one map,  we already have
> utilityCache and can save DSs directly in utilityCache, to distinguish DS
> with other objects in utilityCache I use composite key, the first part of
> which is DATA_STRUCTURES_KEY, second one is DS's name, also DS type can be
> added, this will allow us to create different DS with the same name.
>
> There is draft implementations, all DSs are stored with unique key in
> utilityCache:
> https://github.com/apache/ignite/pull/2046/files
>
> May be there's some reason to store all DS in one Map that I missed?
> Any thoughts?
>
>
> --
> Thanks,
> Mikhail.
>

contention on DataStructure creation/removing

[Mikhail Cherkasov]

Hi all,

All DataStructures are stored in one Map which itself is stored in
utilityCache, this makes high contention on DS creation or removing, it
requires to acquire Map's lock and manipulation with the Map under the
lock. So all threads in cluster should wait for this lock to create or
remove DS.

I don't see any reason to store all DS in one map,  we already have
utilityCache and can save DSs directly in utilityCache, to distinguish DS
with other objects in utilityCache I use composite key, the first part of
which is DATA_STRUCTURES_KEY, second one is DS's name, also DS type can be
added, this will allow us to create different DS with the same name.

There is draft implementations, all DSs are stored with unique key in
utilityCache:
https://github.com/apache/ignite/pull/2046/files

May be there's some reason to store all DS in one Map that I missed?
Any thoughts?


-- 
Thanks,
Mikhail.

[GitHub] ignite pull request #2046: Removed DS map, all DS is added to utilityCache d...

[mcherkasov]

GitHub user mcherkasov opened a pull request:

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

Removed DS map, all DS is added to utilityCache directly

All DSs are stored in one Map which itself is stored in utilityCache, this 
makes high contention on DS creation or removing, it requires lock on the key 
and manipulation with the Map under the lock. So all threads in cluster should 
wait for this lock to create or remove DS.

I don't see any reason to store all DS in one map,  we already have 
utilityCache and can save DSs directly in utilityCache, to distinguish DS with 
other objects in utilityCache I use composite key, the first part of which is 
DATA_STRUCTURES_KEY, second one is DS's name, also DS type can be added, this 
will allow us to create different DS with the same name.



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

$ git pull https://github.com/mcherkasov/ignite ds-creation

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

https://github.com/apache/ignite/pull/2046.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 #2046


commit 85764af902e22df4016b5590e98245935953eed5
Author: mcherkasov 
Date:   2017-05-31T11:39:31Z

Removed DS map, all DS is added to utilityCache directly




---
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 #2044: IGNITE-5320

[devozerov]

Github user devozerov closed the pull request at:

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


---
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 #2045: MemoryPolicyConfiguration.rateTimeInterval proper...

[sergey-chugunov-1985]

GitHub user sergey-chugunov-1985 opened a pull request:

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

MemoryPolicyConfiguration.rateTimeInterval property changed its type to long



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

$ git pull https://github.com/gridgain/apache-ignite ignite-5124-1

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

https://github.com/apache/ignite/pull/2045.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 #2045


commit 9ae106a1c0d20b1bce2399b388b4652ff37a46c5
Author: Sergey Chugunov 
Date:   2017-05-22T17:21:46Z

IGNITE-5124 properties to configure memoryMetrics were added

commit adb905024135f0cdb9f03a09d5680f680a0da455
Author: Sergey Chugunov 
Date:   2017-05-23T11:03:42Z

IGNITE-5124 MemoryPolicy configuration validation test was updated

commit 0068847e746913bcf18339a0ac36380923a8c214
Author: Sergey Chugunov 
Date:   2017-05-24T09:13:03Z

IGNITE-5124 changes in documentation javadocs

commit 0f69ae527aede6880d64435d056d0c603cddf5e1
Author: Sergey Chugunov 
Date:   2017-05-25T12:32:59Z

IGNITE-5124 MemoryConfiguration validation test fixes

commit 1343341458eb6ea96785fe76df6b12348aac0328
Author: Sergey Chugunov 
Date:   2017-05-31T09:59:30Z

IGNITE-5124 rateTimeInterval semantics was changed from seconds to 
milliseconds

commit 1ffb4f591bebcdfea3902aeaba5ad6930c5ab9f9
Author: Sergey Chugunov 
Date:   2017-05-31T11:10:59Z

merge from master




---
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-5357) Replicated cache reads load balancing.

[Alexei Scherbakov (JIRA)]

Alexei Scherbakov created IGNITE-5357:
-

 Summary: Replicated cache reads load balancing.
 Key: IGNITE-5357
 URL: https://issues.apache.org/jira/browse/IGNITE-5357
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 1.6
Reporter: Alexei Scherbakov
 Fix For: 2.2


Currently all read requests from client node to replicated cache will go 
through primary node for key.

Need to select random affinity node in topology and send request here (only if 
readFromBackups=true)



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

[jira] [Created] (IGNITE-5356) .NET: Peer deployment does not load runtime dependencies

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-5356:
--

 Summary: .NET: Peer deployment does not load runtime dependencies
 Key: IGNITE-5356
 URL: https://issues.apache.org/jira/browse/IGNITE-5356
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Affects Versions: 2.1
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 2.1


Discovered while testing in LINQPad:
* Start Apache.Ignite.exe with enabled peer loading
* Run a computation from LINQPad that uses {{Dump}} extension method

It fails with "Cannot load LINQPad assembly" error, because CLR tries to load 
that assembly during job execution, not during deserialization.

We should wrap {{ExecuteRemote}} in a {{PeerAssemblyResolver}} to handle 
runtime assembly requests.



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

[GitHub] ignite pull request #2044: IGNITE-5320

[devozerov]

GitHub user devozerov opened a pull request:

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

IGNITE-5320



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

$ git pull https://github.com/gridgain/apache-ignite ignite-5320

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

https://github.com/apache/ignite/pull/2044.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 #2044


commit c371dac0922599b661d101670db53ab133d7b214
Author: devozerov 
Date:   2017-05-31T07:56:11Z

WIP on JDBC.

commit 3c5231fa86c1c861b757a5fdae460527e49583bb
Author: devozerov 
Date:   2017-05-31T08:02:03Z

WIP.

commit 53aa78a58db52324741064b8049a5a0abc8b9f57
Author: devozerov 
Date:   2017-05-31T08:05:50Z

Removed H2Schema.cacheName. Now need to remove context.

commit e9f7f0d2015b335113ab397aa8d12f37331daad1
Author: devozerov 
Date:   2017-05-31T08:08:17Z

WIP.

commit 7bcb0af2c0ea0ca49a4535ebdc121992fcc78383
Author: devozerov 
Date:   2017-05-31T08:16:55Z

WIP.

commit d3a5972ae925675a08dd03ee465a19bda5b9e6b8
Author: devozerov 
Date:   2017-05-31T08:29:06Z

WIP.

commit 5ad2e953f050e30bff038fe1bb9543e38df4c706
Author: devozerov 
Date:   2017-05-31T09:13:09Z

WIP.

commit 8fc6234781ba1281451fc8eb4130561d31032412
Author: devozerov 
Date:   2017-05-31T09:27:40Z

WIP.

commit df5c39d119381024e553d9b56467f7dc59e94868
Author: devozerov 
Date:   2017-05-31T09:36:47Z

registerCache

commit e05db594e9cfd4fba3d8fc04b710c63e812c5ae4
Author: devozerov 
Date:   2017-05-31T09:49:55Z

unregisterCache

commit ae746596c248bab66e6f3075c00ee5ec3ca78e3a
Author: devozerov 
Date:   2017-05-31T09:57:33Z

WIP.

commit e11c6071ee83ca67dd96d2492c27db9c50b1d75f
Author: devozerov 
Date:   2017-05-31T10:00:45Z

Added deprecation.




---
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 #2042: IGNITE-5354 .NET: Fix command line args preferenc...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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 #2043: IGNITE-5097: writing arrays length in varint enco...

[daradurvs]

GitHub user daradurvs opened a pull request:

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

IGNITE-5097: writing arrays length in varint encoding was implemented



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

$ git pull https://github.com/daradurvs/ignite ignite-5097_2

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

https://github.com/apache/ignite/pull/2043.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 #2043


commit 5af11ed85fe033ab2d4b70de7b44c584acb376d8
Author: Vyacheslav Daradur 
Date:   2017-05-31T08:41:56Z

ignite-5097: writing arrays length in varint encoding was implemented




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

Re: IgniteCompute async methods do not return ComputeTaskFuture

[Yakov Zhdanov]

Here is the scenario we cannot support for now. User cannot cancel tasks
after master node is restarted. Of course, we need to restore
IgniteCompute.cancelTask(sesId) first.

I am against  changing closures execution mechanics. I would better
simplify and optimize task execution. This way, both tasks and lightweight
closures will benefit.

--Yakov

[jira] [Created] (IGNITE-5355) Create task with release tools

[Aleksey Chetaev (JIRA)]

Aleksey Chetaev created IGNITE-5355:
---

 Summary: Create task with release tools
 Key: IGNITE-5355
 URL: https://issues.apache.org/jira/browse/IGNITE-5355
 Project: Ignite
  Issue Type: Task
  Components: documentation
Reporter: Aleksey Chetaev
 Fix For: 2.1


1. Create task for auto-generate HTML formatted releases notes



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

Re: New thin JDBC driver

[Vladimir Ozerov]

I think I will add completely *new *top-level bean "SqlConfiguration". For
now it will contain:

1) Long query warning timeout (it doesn't make sense anymore on cache
configuration)
2) SQL function classes (also move from cache config)
3) Listener parameters: host, port, max cursors

On Thu, May 25, 2017 at 10:19 AM, Alexander Fedotov <
alexander.fedot...@gmail.com> wrote:

> Hi all,
>
> I have a concern regarding 2).
> "SQL listener" sounds a bit confusing in scope of IgniteConfiguration since
> it doesn't provide a hint on its real purpose.
> In Oracle, SQL listener is more like our CommunicationSpi config.
>
> Kind regards,
> Alex
>
> 25 мая 2017 г. 4:24 AM пользователь "Denis Magda" 
> написал:
>
> > 1) Let's have separate connection string "jdbc:ignite:*thin*://" to avoid
> > any confusion and interference with old drivers.
>
> I would use “jdbc:ignite://“ for the newest driver not forcing to use
> “thin” in the connection string. I think it’s fine to break the
> compatibility there since “jdbc:ignite://“ is used by REST based driver.
>
> —
> Denis
>
> > On May 24, 2017, at 5:51 AM, Vladimir Ozerov 
> wrote:
> >
> > Igniters,
> >
> > Currently we have two JDBC drivers:
> > v1 - old thin driver, deprecated, works over GridClient
> > v2 - fat driver, works over Ignite started in "client" mode.
> >
> > Both of them have the same connection string "jdbc:ignite://"
> >
> > Now we are working on new thin driver. It will use almost the same
> protocol
> > as current ODBC driver, and will require only single port to be opened.
> > Also this driver will not be coupled to particular cache. Now I am
> thinking
> > on how to expose it to through public API. My considerations:
> >
> > 1) Let's have separate connection string "jdbc:ignite:*thin*://" to avoid
> > any confusion and interference with old drivers.
> >
> > 2) Let's rename (actually deprecate + duplicate) OdbcConfiguration to
> > SqlListenerConfiguration. This is where users will define port and other
> > server-side parameters. It will be configurable through
> > IgniteConfiguration.sqlListenerConfiguration.
> > I think "listener" is a good term here, as it is also used in
> conventional
> > RDBMS, such as Oracle.
> >
> > 3) We need to decide whether to start listener service by default or not.
> > Tough question. On the one hand, it is convenient if any Ignite node will
> > be able to serve SQL requests with no additional configuration. On the
> > other hand, it consumes resources and threads (GridNioServer), and
> normally
> > users will have limited set of nodes which will serve user requests. For
> > this reason I would not start it by default in the first place.
> >
> > Please share your thoughts, especially about p.2 since I am in great
> doubts
> > about it.
> >
> > Vladimir.
>

[GitHub] ignite pull request #2042: IGNITE-5354 .NET: Fix command line args preferenc...

[ptupitsyn]

GitHub user ptupitsyn opened a pull request:

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

IGNITE-5354 .NET: Fix command line args preference over config file



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

$ git pull https://github.com/ptupitsyn/ignite ignite-5354

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

https://github.com/apache/ignite/pull/2042.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 #2042


commit c0012fbf8ca1519adbc2a5e89809a9aa8e43545e
Author: Pavel Tupitsyn 
Date:   2017-05-31T08:06:08Z

IGNITE-5354 .NET: ConfigSectionName can not be overridden from command line




---
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-5354) .NET: ConfigSectionName can not be overridden from command line

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-5354:
--

 Summary: .NET: ConfigSectionName can not be overridden from 
command line
 Key: IGNITE-5354
 URL: https://issues.apache.org/jira/browse/IGNITE-5354
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 2.1


{{Apache.Ignite.exe}} takes startup arguments from app.config and command line. 
Command line arguments override those from app.config.

This is not the case for {{ConfigSectionName}} and {{ConfigFileName}}.



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

[GitHub] ignite pull request #1979: IGNITE-5054

[devozerov]

Github user devozerov closed the pull request at:

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


---
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 #2024: IGNITE-5317

[devozerov]

Github user devozerov closed the pull request at:

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


---
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 #2039: IGNITE-5273 .NET: MemoryMetrics API improvements ...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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 #1996: Ignite-5242

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-5353) .NET: Pure SQL & DDL example

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-5353:
--

 Summary: .NET: Pure SQL & DDL example
 Key: IGNITE-5353
 URL: https://issues.apache.org/jira/browse/IGNITE-5353
 Project: Ignite
  Issue Type: Improvement
  Components: examples, platforms
Affects Versions: 2.1
Reporter: Pavel Tupitsyn
 Fix For: 2.2


Create an example where all operations are performed via SQL API, not using 
cache API. See IGNITE-5159.



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