[jira] [Updated] (IGNITE-12967) Start cluster snapshot from client node
[ https://issues.apache.org/jira/browse/IGNITE-12967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12967: - Ignite Flags: (was: Docs Required,Release Notes Required) > Start cluster snapshot from client node > --- > > Key: IGNITE-12967 > URL: https://issues.apache.org/jira/browse/IGNITE-12967 > Project: Ignite > Issue Type: Improvement >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Labels: iep-43 > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > Users should be able to start cluster snapshots from client node by sending > compute requests on server node. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11073) Persistence cache snapshot
[ https://issues.apache.org/jira/browse/IGNITE-11073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-11073: - Ignite Flags: Docs Required,Release Notes Required Release Note: Added feature of cluster snapshots for persistence caches > Persistence cache snapshot > -- > > Key: IGNITE-11073 > URL: https://issues.apache.org/jira/browse/IGNITE-11073 > Project: Ignite > Issue Type: New Feature >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Labels: iep-28, iep-43 > Fix For: 2.9 > > Time Spent: 52h 20m > Remaining Estimate: 0h > > *Snapshot requirements* > # Users must have the ability to create a snapshot of persisted user data > (in-memory is out of the scope). > # Users must have the ability to create a snapshot from the cluster under the > load without cluster deactivation. > # The snapshot process must not block for a long time any of the user > transactions (short-time blocks are acceptable). > # The snapshot process must allow creating a data snapshot on each node and > transfer it to any of the remote nodes for internal cluster needs. > # The created snapshot at the cluster-level must be fully consistent from > cluster-wide terms, there should not be any incomplete transactions inside. > # The snapshot of each node must be consistent – cache partitions, binary > meta, etc. must not have unnecessary changes. > *The following API must be available:* > # [public] Java API > # [public] JMX MBean > # [internal] File Transmission -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12975) pyignte sql query should not try to create a cache
[ https://issues.apache.org/jira/browse/IGNITE-12975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Melnichuk updated IGNITE-12975: -- Attachment: IGNITE-12975_Fix_cache_obtaining_method.patch > pyignte sql query should not try to create a cache > -- > > Key: IGNITE-12975 > URL: https://issues.apache.org/jira/browse/IGNITE-12975 > Project: Ignite > Issue Type: Bug > Components: python >Affects Versions: 2.7.6 >Reporter: Isaac Zhu >Priority: Major > Attachments: IGNITE-12975_Fix_cache_obtaining_method.patch > > > I find in this line: > [https://github.com/apache/ignite/blob/master/modules/platforms/python/pyignite/client.py#L395] > When doing an SQL query through the pyignite thin client, it is trying to get > the cache by calling "get_or_create_cache". This caused my ignite instance > returns an "Authorization error" because I was using an account that only can > read cache and does not have permission to create a cache - we implemented a > Security Processor in our ignite cluster to handle the authorization. > I think here call the "self.get_cache" is enough to perform a SQL query -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12975) pyignte sql query should not try to create a cache
[
https://issues.apache.org/jira/browse/IGNITE-12975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17097836#comment-17097836
]
Dmitry Melnichuk commented on IGNITE-12975:
---
[~nifeng2xing] you're absolutely right, {{get_cache()}} is enough.
[~isapego] would you mind to apply a fix?
[^IGNITE-12975_Fix_cache_obtaining_method.patch]
> pyignte sql query should not try to create a cache
> --
>
> Key: IGNITE-12975
> URL: https://issues.apache.org/jira/browse/IGNITE-12975
> Project: Ignite
> Issue Type: Bug
> Components: python
>Affects Versions: 2.7.6
>Reporter: Isaac Zhu
>Priority: Major
> Attachments: IGNITE-12975_Fix_cache_obtaining_method.patch
>
>
> I find in this line:
> [https://github.com/apache/ignite/blob/master/modules/platforms/python/pyignite/client.py#L395]
> When doing an SQL query through the pyignite thin client, it is trying to get
> the cache by calling "get_or_create_cache". This caused my ignite instance
> returns an "Authorization error" because I was using an account that only can
> read cache and does not have permission to create a cache - we implemented a
> Security Processor in our ignite cluster to handle the authorization.
> I think here call the "self.get_cache" is enough to perform a SQL query
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12809) Python client returns fields in wrong order since the 2 row when fields_count>10
[
https://issues.apache.org/jira/browse/IGNITE-12809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17097834#comment-17097834
]
Dmitry Melnichuk commented on IGNITE-12809:
---
[~ezhuravl], you are totally correct in pinpointing the problematic code.
However, you can't just remove the {{sorted()}} function. The {{result}} is of
type {{dict}}, not {{OrderedDict}}. These types are essentially the same since
Python 3.6, but the code must be compatible with Python 3.4. In 3.4 the
{{dict}} object is not retaining the order of its elements, so no sorting will
lead to more random ordering problems. Instead, the correct sorting should be
applied.
Here I attached a diff file, that contains a fix for this problem, alone with a
[^IGNITE-12809_Fix_and_test_value_ordering_for_client_sql.patch] corresponding
test case. [~isapego] could you please look it up.
> Python client returns fields in wrong order since the 2 row when
> fields_count>10
>
>
> Key: IGNITE-12809
> URL: https://issues.apache.org/jira/browse/IGNITE-12809
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.8
>Reporter: Evgenii Zhuravlev
>Assignee: Igor Sapego
>Priority: Major
> Labels: python
> Attachments:
> IGNITE-12809_Fix_and_test_value_ordering_for_client_sql.patch, reproducer.py
>
>
> Reproducer attached.
> If result set is bigger than a page size(1 by default) and there are more
> than 10 fields in an object, then, for all rows after the first query column
> order will be wrong. Looks like column order is being sorted as a string
> instead of number.
> The reason for that is a sorting in api/sql.py:
> https://github.com/apache/ignite/blob/master/modules/platforms/python/pyignite/api/sql.py#L445
> If you remove it, everything will work fine. We need to make sure that this
> is the right solution for this issue.
> Output from reproducer:
> {code:java}
> ['CODE', 'NAME', 'CONTINENT', 'REGION', 'SURFACEAREA', 'INDEPYEAR',
> 'POPULATION', 'LIFEEXPECTANCY', 'GNP', 'GNPOLD', 'LOCALNAME',
> 'GOVERNMENTFORM', 'HEADOFSTATE', 'CAPITAL', 'CODE2']
> ['CHN', 'China', 'Asia', 'Eastern Asia', Decimal('9.5729E+6'), -1523,
> 1277558000, Decimal('71.4'), Decimal('982268'), Decimal('917719'),
> 'Zhongquo', 'PeoplesRepublic', 'Jiang Zemin', 1891, 'CN']
> ['IND', 'India', 'Bharat/India', 'Federal Republic', 'Kocheril Raman
> Narayanan', 1109, 'IN', 'Asia', 'Southern and Central Asia',
> Decimal('3287263'), 1947, 1013662000, Decimal('62.5'), Decimal('447114'),
> Decimal('430572')]
> ['USA', 'United States', 'United States', 'Federal Republic', 'George W.
> Bush', 3813, 'US', 'North America', 'North America', Decimal('9.36352E+6'),
> 1776, 278357000, Decimal('77.1'), Decimal('8.5107E+6'), Decimal('8.1109E+6')]
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12809) Python client returns fields in wrong order since the 2 row when fields_count>10
[
https://issues.apache.org/jira/browse/IGNITE-12809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Melnichuk updated IGNITE-12809:
--
Attachment: IGNITE-12809_Fix_and_test_value_ordering_for_client_sql.patch
> Python client returns fields in wrong order since the 2 row when
> fields_count>10
>
>
> Key: IGNITE-12809
> URL: https://issues.apache.org/jira/browse/IGNITE-12809
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.8
>Reporter: Evgenii Zhuravlev
>Assignee: Igor Sapego
>Priority: Major
> Labels: python
> Attachments:
> IGNITE-12809_Fix_and_test_value_ordering_for_client_sql.patch, reproducer.py
>
>
> Reproducer attached.
> If result set is bigger than a page size(1 by default) and there are more
> than 10 fields in an object, then, for all rows after the first query column
> order will be wrong. Looks like column order is being sorted as a string
> instead of number.
> The reason for that is a sorting in api/sql.py:
> https://github.com/apache/ignite/blob/master/modules/platforms/python/pyignite/api/sql.py#L445
> If you remove it, everything will work fine. We need to make sure that this
> is the right solution for this issue.
> Output from reproducer:
> {code:java}
> ['CODE', 'NAME', 'CONTINENT', 'REGION', 'SURFACEAREA', 'INDEPYEAR',
> 'POPULATION', 'LIFEEXPECTANCY', 'GNP', 'GNPOLD', 'LOCALNAME',
> 'GOVERNMENTFORM', 'HEADOFSTATE', 'CAPITAL', 'CODE2']
> ['CHN', 'China', 'Asia', 'Eastern Asia', Decimal('9.5729E+6'), -1523,
> 1277558000, Decimal('71.4'), Decimal('982268'), Decimal('917719'),
> 'Zhongquo', 'PeoplesRepublic', 'Jiang Zemin', 1891, 'CN']
> ['IND', 'India', 'Bharat/India', 'Federal Republic', 'Kocheril Raman
> Narayanan', 1109, 'IN', 'Asia', 'Southern and Central Asia',
> Decimal('3287263'), 1947, 1013662000, Decimal('62.5'), Decimal('447114'),
> Decimal('430572')]
> ['USA', 'United States', 'United States', 'Federal Republic', 'George W.
> Bush', 3813, 'US', 'North America', 'North America', Decimal('9.36352E+6'),
> 1776, 278357000, Decimal('77.1'), Decimal('8.5107E+6'), Decimal('8.1109E+6')]
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
