date:20221222

DataRegion not releasing memory back to OS

2022-12-22 Thread Humphrey Lopez

Hello,

I've been doing some test with Ignite 2.14, creating one cache filling it
with data and then clearing back the cache, eventually destroy the cache.
I'm using the OpenCensus metrics to get the statistics:
- TotalAllocatedSize
When I test it with persistence Enabled I see that TotalAllocatedSize drops
back to 0 when I invoke the destroy cache method.
But when I do the same with persistence Disabled, the TotalAllocatedSize
doesn't drop back.

I was hoping that when clearing the cache the memory drops, or at least
when I do destroy(). My question is why is this memory given back when
Persistence is Enabled and not when Persistence is disabled, I was hoping
to see the same effect.

I can create a reproducer for this, but maybe it's a known thing.

Humphrey

Issues with using deployment when deploying Ignite on K8S

2022-12-22 Thread Wen Bo (Bill) Li

Hi,

I have encountered an issue in deploying Ignite on Kubernetes using the
deployment object. By following the documentation below, I deployed an
Ignite cluster with 3 instances. However, because these 3 instances started
all at the same time, they did not discover each other at the startup and
became 3 standalone clusters. It will try to discover an existing cluster
and become part of it only when I restart any of the pods. Has anyone
encountered this issue before?

Regards,

-- 

Wen Bo (Bill) Li (he, him, his)
Geotab

Senior Software Developer, Data Platform

Direct
Toll-free

Visit

+1 (416) 908-2988
+1 (877) 431-8221
www.geotab.com

Twitter  | Facebook
 | YouTube
 | LinkedIn

Re: [!!Массовая рассылка]Can't access binary key from Python client

2022-12-22 Thread Ivan Daschinsky

I am afraid, that if you already have ingested your data using old thin
java client, you have no choice but set compact_footer=False to pyignite.

чт, 22 дек. 2022 г. в 14:45, Айсина Роза Мунеровна <
roza.ays...@sbermarket.ru>:

> Oh, we can’t migrate to newer version, so for consistency we will set
> compact_footer = True currently for our thin java client.
>
> Thank you very much for your help!
>
> On 22 Dec 2022, at 2:08 PM, Ivan Daschinsky  wrote:
>
> It is required only for older java client. If you choose client version
> 2.14.0, everything will work automatically. Otherwise, it is advisable to
> set up this flag manually.
> For pyignite it is not required to specify it, it is up to you.
>
> чт, 22 дек. 2022 г. в 13:42, Айсина Роза Мунеровна <
> roza.ays...@sbermarket.ru>:
>
>> Okay, I got that. Thank you for your explanation!
>>
>> Will it be wright and more consistent to set up *compact_footer = True*
>> both in application that creates and fills data (java thin client) and in
>> python client explicitly?
>> Should I somehow put this flag on server config?
>>
>>
>> On 22 Dec 2022, at 1:18 PM, Ivan Daschinsky  wrote:
>>
>> Внимание: Внешний отправитель!
>> Если вы не знаете отправителя - не открывайте вложения, не переходите по
>> ссылкам, не пересылайте письмо!
>>
>> Actually, cache doesn't care about what you put inside it. This is just a
>> configuration of serialization. And this parameter must be the same
>> throughout the cluster. Otherwise, surprises will arise undoubtedly
>>
>>
>>
>> *--*
>>
>> *Роза Айсина*
>> Старший разработчик ПО
>> *СберМаркет* | Доставка из любимых магазинов
>>
>>
>> Email: roza.ays...@sbermarket.ru
>> Mob:
>> Web: sbermarket.ru
>> App: iOS
>> 
>> и Android
>> 
>>
>>
>>
>>
>>
>>
>> *УВЕДОМЛЕНИЕ О КОНФИДЕНЦИАЛЬНОСТИ:* это электронное сообщение и любые
>> документы, приложенные к нему, содержат конфиденциальную информацию.
>> Настоящим уведомляем Вас о том, что, если это сообщение не предназначено
>> Вам, использование, копирование, распространение информации, содержащейся в
>> настоящем сообщении, а также осуществление любых действий на основе этой
>> информации, строго запрещено. Если Вы получили это сообщение по ошибке,
>> пожалуйста, сообщите об этом отправителю по электронной почте и удалите это
>> сообщение.
>> *CONFIDENTIALITY NOTICE:* This email and any files attached to it are
>> confidential. If you are not the intended recipient you are notified that
>> using, copying, distributing or taking any action in reliance on the
>> contents of this information is strictly prohibited. If you have received
>> this email in error please notify the sender and delete this email.
>>
>
>
> --
> Sincerely yours, Ivan Daschinskiy
>
>
> *--*
>
> *Роза Айсина*
>
> Старший разработчик ПО
>
> *СберМаркет* | Доставка из любимых магазинов
>
>
>
> Email: roza.ays...@sbermarket.ru
>
> Mob:
>
> Web: sbermarket.ru
>
> App: iOS
> 
> и Android
> 
>
>
>
> *УВЕДОМЛЕНИЕ О КОНФИДЕНЦИАЛЬНОСТИ:* это электронное сообщение и любые
> документы, приложенные к нему, содержат конфиденциальную информацию.
> Настоящим уведомляем Вас о том, что, если это сообщение не предназначено
> Вам, использование, копирование, распространение информации, содержащейся в
> настоящем сообщении, а также осуществление любых действий на основе этой
> информации, строго запрещено. Если Вы получили это сообщение по ошибке,
> пожалуйста, сообщите об этом отправителю по электронной почте и удалите это
> сообщение.
> *CONFIDENTIALITY NOTICE:* This email and any files attached to it are
> confidential. If you are not the intended recipient you are notified that
> using, copying, distributing or taking any action in reliance on the
> contents of this information is strictly prohibited. If you have received
> this email in error please notify the sender and delete this email.
>


-- 
Sincerely yours, Ivan Daschinskiy

Re: How to use Hash Join in SQL API?

2022-12-22 Thread Stephen Darlington

Are you saying that you have no indexes other than the primary key? What is the 
primary key for RetailProductFeatures?

> On 22 Dec 2022, at 13:00, Айсина Роза Мунеровна  
> wrote:
> 
> Hi Stephen!
> 
> I use this DDLl to create table (all tables are created this way): 
> 
> CREATE TABLE IF NOT EXISTS PUBLIC.ProductFeatures
> (
> product_sku INT PRIMARY KEY,
> total_cnt_orders_with_sku INT
> )
> WITH "CACHE_NAME=PUBLIC_ProductFeatures, KEY_TYPE=io.sbmt.ProductFeaturesKey, 
> VALUE_TYPE=io.sbmt.ProductFeaturesValue, AFFINITY_KEY=product_sku, 
> TEMPLATE=PARTITIONED, BACKUPS=1
> 
> So I have affinity index and primary key index and what I see in indexes 
> system table: 
> ++
> |INDEX_NAME  |
> ++
> |_key_PK_hash|
> |__SCAN_ |
> |_key_PK |
> |AFFINITY_KEY|
> ++
> 
> 
>> On 22 Dec 2022, at 1:21 PM, Stephen Darlington 
>>  wrote:
>> 
>> What indexes have you created on RetailerProductFeatures? In general, 
>> there’s no need to specify the index to use in your query.
>> 
>>> On 22 Dec 2022, at 09:53, Айсина Роза Мунеровна >> > wrote:
>>> 
>>> Hi!
>>> 
>>> Thank you for your replies!
>>> 
>>> I tried to specify any index except primary key index and explained showed, 
>>> that SCAN is used which, I guess, is full table scan: 
>>> 
>>> explain
>>> SELECT ProductFeatures.product_sku,
>>>ProductFeatures.total_cnt_orders_with_sku,
>>>RetailerProductFeatures.mean_daily_sku_retailer_popularity
>>> FROM ProductFeatures
>>>  LEFT JOIN RetailerProductFeatures USE INDEX(PUBLIC."_key_PK_hash")
>>>ON ProductFeatures.product_sku = 
>>> RetailerProductFeatures.product_sku
>>>AND RetailerProductFeatures.retailer_id = 142
>>> WHERE ProductFeatures.product_sku IN (52864, 1582957, 110319, 1477711, 
>>> 272024)
>>> ;
>>> 
>>> SELECT
>>> __Z0.PRODUCT_SKU AS __C0_0,
>>> __Z0.TOTAL_CNT_ORDERS_WITH_SKU AS __C0_1,
>>> __Z1.MEAN_DAILY_SKU_RETAILER_POPULARITY AS __C0_2
>>> FROM PUBLIC.PRODUCTFEATURES __Z0
>>> /* PUBLIC."_key_PK": PRODUCT_SKU IN(52864, 1582957, 110319, 1477711, 
>>> 272024) */
>>> /* WHERE __Z0.PRODUCT_SKU IN(52864, 1582957, 110319, 1477711, 272024)
>>> */
>>> LEFT OUTER JOIN PUBLIC.RETAILERPRODUCTFEATURES __Z1 USE INDEX 
>>> ("_key_PK_hash")
>>> /* PUBLIC.RETAILERPRODUCTFEATURES.__SCAN_ */
>>> ON (__Z1.RETAILER_ID = 142)
>>> AND (__Z0.PRODUCT_SKU = __Z1.PRODUCT_SKU)
>>> WHERE __Z0.PRODUCT_SKU IN(52864, 1582957, 110319, 1477711, 272024)
>>> 
>>> So I guess there is no way to specify more “fast” index because the main 
>>> goal is to speed up our JOIN queries. 
>>> 
>>> Thanks!
>>> 
 On 21 Dec 2022, at 9:06 PM, Николай Ижиков >>> > wrote:
 
 Hello.
 
 It seems, you should replace `HASH_JOIN_IDX` with your actual index name.
 You can find all indexes with `SELECT * FROM SYS.INDEXES`
 
> 21 дек. 2022 г., в 20:43, Stephen Darlington 
>  > написал(а):
> 
> I don’t think it’s ever been in Ignite.
> 
>> On 21 Dec 2022, at 16:49, Айсина Роза Мунеровна 
>> mailto:roza.ays...@sbermarket.ru>> wrote:
>> 
>> Hi Stephen!
>> 
>> Sorry, I forgot to attach link on doc: 
>> https://ignite.apache.org/docs/2.11.1/SQL/distributed-joins#hash-joins 
>> 
>> 
>> We use 2.13.0 Ignite version.
>> So this feature was deleted from releases after 2.11? :(
>> 
>>> On 21 Dec 2022, at 7:43 PM, Stephen Darlington 
>>> >> > wrote:
>>> 
>>> Внимание: Внешний отправитель!
>>> Если вы не знаете отправителя - не открывайте вложения, не переходите 
>>> по ссылкам, не пересылайте письмо!
>>> 
>>> Where did you get that syntax from? I don’t think Ignite supports hash 
>>> joins, though there are other distributions of Ignite that do.
>>> 
 On 21 Dec 2022, at 16:22, Айсина Роза Мунеровна 
 mailto:roza.ays...@sbermarket.ru>> wrote:
 
 Hola again!
 
 I have a problem when trying to use Hah Join in SQL API.
 I am using this doc: 
 
 What I am doing: 
 
 query = """
 SELECT pf.product_sku,
pf.total_cnt_orders_with_sku,
rpf.mean_daily_sku_retailer_popularity
 FROM ProductFeatures AS pf
  LEFT JOIN RetailerProductFeatures AS rpf 
 USE INDEX(HASH_JOIN_IDX)
ON pf.product_sku = rpf.product_sku
AND rpf.retailer_id = 142
 WHERE pf.product_sku IN (52864, 1582957, 110319, 1477711, 272024)
 """
 
 data = next(
 ignite_client.sql(
 query,
 distributed_joins=False,
>>

Re: How to use Hash Join in SQL API?

2022-12-22 Thread Айсина Роза Мунеровна

Hi Stephen!

I use this DDLl to create table (all tables are created this way):

CREATE TABLE IF NOT EXISTS PUBLIC.ProductFeatures
(
product_sku INT PRIMARY KEY,
total_cnt_orders_with_sku INT
)
WITH "CACHE_NAME=PUBLIC_ProductFeatures, KEY_TYPE=io.sbmt.ProductFeaturesKey, 
VALUE_TYPE=io.sbmt.ProductFeaturesValue, AFFINITY_KEY=product_sku, 
TEMPLATE=PARTITIONED, BACKUPS=1

So I have affinity index and primary key index and what I see in indexes system 
table:
++
|INDEX_NAME  |
++
|_key_PK_hash|
|__SCAN_ |
|_key_PK |
|AFFINITY_KEY|
++


On 22 Dec 2022, at 1:21 PM, Stephen Darlington 
 wrote:

What indexes have you created on RetailerProductFeatures? In general, there’s 
no need to specify the index to use in your query.

On 22 Dec 2022, at 09:53, Айсина Роза Мунеровна 
mailto:roza.ays...@sbermarket.ru>> wrote:

Hi!

Thank you for your replies!

I tried to specify any index except primary key index and explained showed, 
that SCAN is used which, I guess, is full table scan:


explain
SELECT ProductFeatures.product_sku,
   ProductFeatures.total_cnt_orders_with_sku,
   RetailerProductFeatures.mean_daily_sku_retailer_popularity
FROM ProductFeatures
 LEFT JOIN RetailerProductFeatures USE INDEX(PUBLIC."_key_PK_hash")
   ON ProductFeatures.product_sku = 
RetailerProductFeatures.product_sku
   AND RetailerProductFeatures.retailer_id = 142
WHERE ProductFeatures.product_sku IN (52864, 1582957, 110319, 1477711, 272024)
;

SELECT
__Z0.PRODUCT_SKU AS __C0_0,
__Z0.TOTAL_CNT_ORDERS_WITH_SKU AS __C0_1,
__Z1.MEAN_DAILY_SKU_RETAILER_POPULARITY AS __C0_2
FROM PUBLIC.PRODUCTFEATURES __Z0
/* PUBLIC."_key_PK": PRODUCT_SKU IN(52864, 1582957, 110319, 1477711, 
272024) */
/* WHERE __Z0.PRODUCT_SKU IN(52864, 1582957, 110319, 1477711, 272024)
*/
LEFT OUTER JOIN PUBLIC.RETAILERPRODUCTFEATURES __Z1 USE INDEX ("_key_PK_hash")
/* PUBLIC.RETAILERPRODUCTFEATURES.__SCAN_ */
ON (__Z1.RETAILER_ID = 142)
AND (__Z0.PRODUCT_SKU = __Z1.PRODUCT_SKU)
WHERE __Z0.PRODUCT_SKU IN(52864, 1582957, 110319, 1477711, 272024)

So I guess there is no way to specify more “fast” index because the main goal 
is to speed up our JOIN queries.

Thanks!

On 21 Dec 2022, at 9:06 PM, Николай Ижиков 
mailto:nizhi...@apache.org>> wrote:

Hello.

It seems, you should replace `HASH_JOIN_IDX` with your actual index name.
You can find all indexes with `SELECT * FROM SYS.INDEXES`

21 дек. 2022 г., в 20:43, Stephen Darlington 
mailto:stephen.darling...@gridgain.com>> 
написал(а):

I don’t think it’s ever been in Ignite.

On 21 Dec 2022, at 16:49, Айсина Роза Мунеровна 
mailto:roza.ays...@sbermarket.ru>> wrote:

Hi Stephen!

Sorry, I forgot to attach link on doc:
https://ignite.apache.org/docs/2.11.1/SQL/distributed-joins#hash-joins

We use 2.13.0 Ignite version.
So this feature was deleted from releases after 2.11? :(

On 21 Dec 2022, at 7:43 PM, Stephen Darlington 
mailto:stephen.darling...@gridgain.com>> wrote:

Внимание: Внешний отправитель!
Если вы не знаете отправителя - не открывайте вложения, не переходите по 
ссылкам, не пересылайте письмо!

Where did you get that syntax from? I don’t think Ignite supports hash joins, 
though there are other distributions of Ignite that do.

On 21 Dec 2022, at 16:22, Айсина Роза Мунеровна 
mailto:roza.ays...@sbermarket.ru>> wrote:

Hola again!

I have a problem when trying to use Hah Join in SQL API.
I am using this doc:

What I am doing:


query = """
SELECT pf.product_sku,
   pf.total_cnt_orders_with_sku,
   rpf.mean_daily_sku_retailer_popularity
FROM ProductFeatures AS pf
 LEFT JOIN RetailerProductFeatures AS rpf
USE INDEX(HASH_JOIN_IDX)
   ON pf.product_sku = rpf.product_sku
   AND rpf.retailer_id = 142
WHERE pf.product_sku IN (52864, 1582957, 110319, 1477711, 272024)
"""

data = next(
ignite_client.sql(
query,
distributed_joins=False,
enforce_join_order=True,
collocated=True,
)
)

What I get:
Index "HASH_JOIN_IDX" not found


So basically it is simple join SQL query that works fine without hash join 
index.
Both tables have affinity key product_sku and this column is part of primary 
key.

When I look at index system tables I see that there is _key_PK_hash index for 
both tables
But I had no luck to specify it - SQL parser can’t find it either.

Please help!
--

Роза Айсина
Старший разработчик ПО
СберМаркет | Доставка из любимых магазинов



Email: roza.ays...@sbermarket.ru
Mob:
Web: sbermarket.ru
App: 
iOS
 и 
Android







УВЕДОМЛЕНИЕ О КОНФИДЕНЦИАЛЬНОСТИ:

Re: [!!Массовая рассылка]Can't access binary key from Python client

2022-12-22 Thread Айсина Роза Мунеровна

Oh, we can’t migrate to newer version, so for consistency we will set
compact_footer = True currently for our thin java client.

Thank you very much for your help!

On 22 Dec 2022, at 2:08 PM, Ivan Daschinsky wrote:

It is required only for older java client. If you choose client version 2.14.0,
everything will work automatically. Otherwise, it is advisable to set up this
flag manually.
For pyignite it is not required to specify it, it is up to you.

чт, 22 дек. 2022 г. в 13:42, Айсина Роза Мунеровна
mailto:roza.ays...@sbermarket.ru>>:
Okay, I got that. Thank you for your explanation!

Will it be wright and more consistent to set up compact_footer = True both in
application that creates and fills data (java thin client) and in python client
explicitly?
Should I somehow put this flag on server config?

On 22 Dec 2022, at 1:18 PM, Ivan Daschinsky
mailto:ivanda...@gmail.com>> wrote:

Внимание: Внешний отправитель!
Если вы не знаете отправителя - не открывайте вложения, не переходите по
ссылкам, не пересылайте письмо!

Actually, cache doesn't care about what you put inside it. This is just a
configuration of serialization. And this parameter must be the same throughout
the cluster. Otherwise, surprises will arise undoubtedly

Роза Айсина
Старший разработчик ПО
СберМаркет | Доставка из любимых магазинов

Email: roza.ays...@sbermarket.ru
Mob:
Web: sbermarket.ru
App:
iOS
и
Android

УВЕДОМЛЕНИЕ О КОНФИДЕНЦИАЛЬНОСТИ: это электронное сообщение и любые документы,
приложенные к нему, содержат конфиденциальную информацию. Настоящим уведомляем
Вас о том, что, если это сообщение не предназначено Вам, использование,
копирование, распространение информации, содержащейся в настоящем сообщении, а
также осуществление любых действий на основе этой информации, строго запрещено.
Если Вы получили это сообщение по ошибке, пожалуйста, сообщите об этом
отправителю по электронной почте и удалите это сообщение.
CONFIDENTIALITY NOTICE: This email and any files attached to it are
confidential. If you are not the intended recipient you are notified that
using, copying, distributing or taking any action in reliance on the contents
of this information is strictly prohibited. If you have received this email in
error please notify the sender and delete this email.

--
Sincerely yours, Ivan Daschinskiy

Роза Айсина

Старший разработчик ПО

СберМаркет | Доставка из любимых магазинов

Email: roza.ays...@sbermarket.ru

Mob:

Web: sbermarket.ru

App:
iOS
и
Android

Re: Read from backup with PRIMARY_SYNC

2022-12-22 Thread Surinder Mehra

Thanks Stephen

On Wed, Dec 21, 2022 at 11:54 PM Stephen Darlington <
stephen.darling...@gridgain.com> wrote:

> Please note that volunteers answer questions here. If you need SLAs for
> answers to your questions, there are companies that provide support.
>
> Full sync would work. You could also use transactions.
>
> On 21 Dec 2022, at 17:58, Surinder Mehra  wrote:
>
> Gentle reminder.
>
> On Tue, 20 Dec 2022, 12:53 Surinder Mehra,  wrote:
>
>> Hi,
>> If we have cache synchronization mode as Primary Sync and read from
>> backup as true(default), would this cause consistency issues if primary
>> goes down without flushing all data to disk.
>> I understand WAL is used to replay unflushed data when a node comes back
>> online again. But if say out of 10 records written to cache, only 5 of them
>> were written to disk by checkpointing thread and data was not replicated to
>> the backup node yet(PRIMARY-SYNC) when primary node went node, the client
>> would assume backup node would have all 10 records . But it might not be
>> the case.
>>
>> So am I correct in assuming we need to either turn off read from backup
>> or change cache synchronization mode to FULL-SYNC
>>
>> Answer to stackoverflow question below suggests disabling read from
>> backup. Do we need to disable it even in FULL-SYNC mode ?
>>
>>
>> https://stackoverflow.com/questions/67598175/ignite-read-stale-data-from-backup-node
>>
>
>

Re: [!!Массовая рассылка]Can't access binary key from Python client

2022-12-22 Thread Ivan Daschinsky

It is required only for older java client. If you choose client version
2.14.0, everything will work automatically. Otherwise, it is advisable to
set up this flag manually.
For pyignite it is not required to specify it, it is up to you.

чт, 22 дек. 2022 г. в 13:42, Айсина Роза Мунеровна <
roza.ays...@sbermarket.ru>:

> Okay, I got that. Thank you for your explanation!
>
> Will it be wright and more consistent to set up *compact_footer = True*
> both in application that creates and fills data (java thin client) and in
> python client explicitly?
> Should I somehow put this flag on server config?
>
>
> On 22 Dec 2022, at 1:18 PM, Ivan Daschinsky  wrote:
>
> Внимание: Внешний отправитель!
> Если вы не знаете отправителя - не открывайте вложения, не переходите по
> ссылкам, не пересылайте письмо!
>
> Actually, cache doesn't care about what you put inside it. This is just a
> configuration of serialization. And this parameter must be the same
> throughout the cluster. Otherwise, surprises will arise undoubtedly
>
>
>
> *--*
>
> *Роза Айсина*
>
> Старший разработчик ПО
>
> *СберМаркет* | Доставка из любимых магазинов
>
>
>
> Email: roza.ays...@sbermarket.ru
>
> Mob:
>
> Web: sbermarket.ru
>
> App: iOS
> 
> и Android
> 
>
>
>
> *УВЕДОМЛЕНИЕ О КОНФИДЕНЦИАЛЬНОСТИ:* это электронное сообщение и любые
> документы, приложенные к нему, содержат конфиденциальную информацию.
> Настоящим уведомляем Вас о том, что, если это сообщение не предназначено
> Вам, использование, копирование, распространение информации, содержащейся в
> настоящем сообщении, а также осуществление любых действий на основе этой
> информации, строго запрещено. Если Вы получили это сообщение по ошибке,
> пожалуйста, сообщите об этом отправителю по электронной почте и удалите это
> сообщение.
> *CONFIDENTIALITY NOTICE:* This email and any files attached to it are
> confidential. If you are not the intended recipient you are notified that
> using, copying, distributing or taking any action in reliance on the
> contents of this information is strictly prohibited. If you have received
> this email in error please notify the sender and delete this email.
>


-- 
Sincerely yours, Ivan Daschinskiy

Re: [!!Массовая рассылка]Can't access binary key from Python client

2022-12-22 Thread Айсина Роза Мунеровна

Okay, I got that. Thank you for your explanation!

Will it be wright and more consistent to set up compact_footer = True both in 
application that creates and fills data (java thin client) and in python client 
explicitly?
Should I somehow put this flag on server config?


On 22 Dec 2022, at 1:18 PM, Ivan Daschinsky  wrote:

Внимание: Внешний отправитель!
Если вы не знаете отправителя - не открывайте вложения, не переходите по 
ссылкам, не пересылайте письмо!

Actually, cache doesn't care about what you put inside it. This is just a 
configuration of serialization. And this parameter must be the same throughout 
the cluster. Otherwise, surprises will arise undoubtedly




--

Роза Айсина

Старший разработчик ПО

СберМаркет | Доставка из любимых магазинов



Email: roza.ays...@sbermarket.ru

Mob:

Web: sbermarket.ru

App: 
iOS
 и 
Android



УВЕДОМЛЕНИЕ О КОНФИДЕНЦИАЛЬНОСТИ: это электронное сообщение и любые документы, 
приложенные к нему, содержат конфиденциальную информацию. Настоящим уведомляем 
Вас о том, что, если это сообщение не предназначено Вам, использование, 
копирование, распространение информации, содержащейся в настоящем сообщении, а 
также осуществление любых действий на основе этой информации, строго запрещено. 
Если Вы получили это сообщение по ошибке, пожалуйста, сообщите об этом 
отправителю по электронной почте и удалите это сообщение.
CONFIDENTIALITY NOTICE: This email and any files attached to it are 
confidential. If you are not the intended recipient you are notified that 
using, copying, distributing or taking any action in reliance on the contents 
of this information is strictly prohibited. If you have received this email in 
error please notify the sender and delete this email.

Re: How to use Hash Join in SQL API?

2022-12-22 Thread Stephen Darlington

What indexes have you created on RetailerProductFeatures? In general, there’s 
no need to specify the index to use in your query.

> On 22 Dec 2022, at 09:53, Айсина Роза Мунеровна  
> wrote:
> 
> Hi!
> 
> Thank you for your replies!
> 
> I tried to specify any index except primary key index and explained showed, 
> that SCAN is used which, I guess, is full table scan: 
> 
> explain
> SELECT ProductFeatures.product_sku,
>ProductFeatures.total_cnt_orders_with_sku,
>RetailerProductFeatures.mean_daily_sku_retailer_popularity
> FROM ProductFeatures
>  LEFT JOIN RetailerProductFeatures USE INDEX(PUBLIC."_key_PK_hash")
>ON ProductFeatures.product_sku = 
> RetailerProductFeatures.product_sku
>AND RetailerProductFeatures.retailer_id = 142
> WHERE ProductFeatures.product_sku IN (52864, 1582957, 110319, 1477711, 272024)
> ;
> 
> SELECT
> __Z0.PRODUCT_SKU AS __C0_0,
> __Z0.TOTAL_CNT_ORDERS_WITH_SKU AS __C0_1,
> __Z1.MEAN_DAILY_SKU_RETAILER_POPULARITY AS __C0_2
> FROM PUBLIC.PRODUCTFEATURES __Z0
> /* PUBLIC."_key_PK": PRODUCT_SKU IN(52864, 1582957, 110319, 1477711, 
> 272024) */
> /* WHERE __Z0.PRODUCT_SKU IN(52864, 1582957, 110319, 1477711, 272024)
> */
> LEFT OUTER JOIN PUBLIC.RETAILERPRODUCTFEATURES __Z1 USE INDEX ("_key_PK_hash")
> /* PUBLIC.RETAILERPRODUCTFEATURES.__SCAN_ */
> ON (__Z1.RETAILER_ID = 142)
> AND (__Z0.PRODUCT_SKU = __Z1.PRODUCT_SKU)
> WHERE __Z0.PRODUCT_SKU IN(52864, 1582957, 110319, 1477711, 272024)
> 
> So I guess there is no way to specify more “fast” index because the main goal 
> is to speed up our JOIN queries. 
> 
> Thanks!
> 
>> On 21 Dec 2022, at 9:06 PM, Николай Ижиков  wrote:
>> 
>> Hello.
>> 
>> It seems, you should replace `HASH_JOIN_IDX` with your actual index name.
>> You can find all indexes with `SELECT * FROM SYS.INDEXES`
>> 
>>> 21 дек. 2022 г., в 20:43, Stephen Darlington 
>>>  написал(а):
>>> 
>>> I don’t think it’s ever been in Ignite.
>>> 
 On 21 Dec 2022, at 16:49, Айсина Роза Мунеровна >>> > wrote:
 
 Hi Stephen!
 
 Sorry, I forgot to attach link on doc: 
 https://ignite.apache.org/docs/2.11.1/SQL/distributed-joins#hash-joins 
 
 
 We use 2.13.0 Ignite version.
 So this feature was deleted from releases after 2.11? :(
 
> On 21 Dec 2022, at 7:43 PM, Stephen Darlington 
>  > wrote:
> 
> Внимание: Внешний отправитель!
> Если вы не знаете отправителя - не открывайте вложения, не переходите по 
> ссылкам, не пересылайте письмо!
> 
> Where did you get that syntax from? I don’t think Ignite supports hash 
> joins, though there are other distributions of Ignite that do.
> 
>> On 21 Dec 2022, at 16:22, Айсина Роза Мунеровна 
>> mailto:roza.ays...@sbermarket.ru>> wrote:
>> 
>> Hola again!
>> 
>> I have a problem when trying to use Hah Join in SQL API.
>> I am using this doc: 
>> 
>> What I am doing: 
>> 
>> query = """
>> SELECT pf.product_sku,
>>pf.total_cnt_orders_with_sku,
>>rpf.mean_daily_sku_retailer_popularity
>> FROM ProductFeatures AS pf
>>  LEFT JOIN RetailerProductFeatures AS rpf 
>> USE INDEX(HASH_JOIN_IDX)
>>ON pf.product_sku = rpf.product_sku
>>AND rpf.retailer_id = 142
>> WHERE pf.product_sku IN (52864, 1582957, 110319, 1477711, 272024)
>> """
>> 
>> data = next(
>> ignite_client.sql(
>> query,
>> distributed_joins=False,
>> enforce_join_order=True,
>> collocated=True,
>> )
>> )
>> 
>> What I get: 
>> Index "HASH_JOIN_IDX" not found
>> 
>> 
>> So basically it is simple join SQL query that works fine without hash 
>> join index.
>> Both tables have affinity key product_sku and this column is part of 
>> primary key. 
>> 
>> When I look at index system tables I see that there is _key_PK_hash 
>> index for both tables
>> But I had no luck to specify it - SQL parser can’t find it either. 
>> 
>> Please help!
>> --
>> 
>> Роза Айсина
>> Старший разработчик ПО
>> СберМаркет | Доставка из любимых магазинов
>>  
>> Email: roza.ays...@sbermarket.ru 
>> Mob:
>> Web: sbermarket.ru 
>> App: iOS 
>> 
>>  и Android 
>> 
>>  
>> 
>> 
>> 
>> 
>> УВЕДОМ

Re: [!!Массовая рассылка]Can't access binary key from Python client

2022-12-22 Thread Ivan Daschinsky

Actually, cache doesn't care about what you put inside it. This is just a
configuration of serialization. And this parameter must be the same
throughout the cluster. Otherwise, surprises will arise undoubtedly

Re: [!!Массовая рассылка]Can't access binary key from Python client

2022-12-22 Thread Ivan Daschinsky

It depends. If your data in cluster is already with compactFooter=false (if
you use old java client where compactFooter is false by default and all
your data were ingested by this client)
, you should disable it in python like this:
client = Client(compact_footer=False)

Actually, this discrepancy of binary configuration is a really bad thing.





чт, 22 дек. 2022 г. в 12:20, Айсина Роза Мунеровна <
roza.ays...@sbermarket.ru>:

> Hi Ivan!
>
> Thank you for your reply!
>
> I tested your snippets with client and server node.
> When I raise server node in the snippet - everything works as expected,
> the same output (key exists).
> When I raise cluster manually on localhost and raise client node in the
> snippet - I have None in output.
>
> I used this dependency:
> pyignite = "0.5.2”  in Python
> implementation group: 'org.apache.ignite', name: 'ignite-core', version:
> ‘2.13.0’ in Java
>
> The same version that we have for production cluster.
>
> So how can I fix this? And where - in Python connection or server config?
>
> Thanks!
>
>
> On 22 Dec 2022, at 10:40 AM, Ivan Daschinsky  wrote:
>
> Внимание: Внешний отправитель!
> Если вы не знаете отправителя - не открывайте вложения, не переходите по
> ссылкам, не пересылайте письмо!
>
> Firstly, please run the java snippet, then run the python snippet
> I got this output:
> /home/ivandasch/.virtualenvs/pyignite-py38/bin/python
> /home/ivandasch/.config/JetBrains/PyCharm2022.2/scratches/scratch.py
> ValueType(name='test', version=1)
>
> чт, 22 дек. 2022 г. в 10:40, Ivan Daschinsky :
>
>> Just tried on (ignite 2.13.0 server, ignite-client on master, pyignite on
>> 0.6.0)
>>
>> Java code:
>>
>> import org.apache.ignite.Ignition;
>> import org.apache.ignite.binary.BinaryObject;
>> import org.apache.ignite.client.ClientCache;
>> import org.apache.ignite.client.IgniteClient;
>> import org.apache.ignite.configuration.ClientConfiguration;
>>
>> class Scratch {
>> public static void main(String[] args) {
>> try (IgniteClient client = Ignition.startClient(new
>> ClientConfiguration()
>> .setAddresses("127.0.0.1:10800", "127.0.0.1:10801", "
>> 127.0.0.1:10802"))) {
>>
>> ClientCache cache =
>> client.getOrCreateCache("test").withKeepBinary();
>>
>> BinaryObject key =
>> client.binary().builder("KeyType").setField("id", 10,
>> Integer.class).build();
>> BinaryObject val =
>> client.binary().builder("ValueType").setField("name", "test",
>> String.class).build();
>>
>> cache.put(key, val);
>> }
>> }
>> }
>>
>> Python code:
>>
>> from pyignite import Client
>> from pyignite import GenericObjectMeta
>> from pyignite.datatypes import IntObject, String
>>
>> class Key(
>> metaclass=GenericObjectMeta,
>> type_name="KeyType",
>> schema={
>> 'id': IntObject,
>> },
>> version=1,
>> ):
>> pass
>>
>> class Value(
>> metaclass=GenericObjectMeta,
>> type_name="ValueType",
>> schema={
>> 'name': String,
>> },
>> version=1,
>> ):
>> pass
>>
>> client = Client()
>> client.connect([('127.0.0.1', 10800 + i) for i in range(0, 3)])
>> cache = client.get_or_create_cache("test")
>>
>> print(cache.get(Key(id=10)))
>>
>> Everything works as expected.
>>
>> I guess that you used the version of ignite-core (thin-client) older than
>> 2.14.0.
>> In that version, compactFooter equals to false, but on server side and
>> pyignite it is by default enabled.
>>
>> But pyignite has an ability to detect this param after fetching the data.
>> That is the reason why you code started working after fetching few data by
>> a scan query.
>>
>> чт, 22 дек. 2022 г. в 09:13, Ivan Daschinsky :
>>
>>> Couls you please specify the exact versions of pyignite and ignite-core
>>> (java thin client)?
>>>
>>> ср, 21 дек. 2022 г., 18:36 Айсина Роза Мунеровна <
>>> roza.ays...@sbermarket.ru>:
>>>
 Hola again!

 I accidently discovered some strange behaviour when trying to get value
 by key in Python.

 I do this in part 3:

 cache = ignite_client.get_cache("PUBLIC_ProductFeatures")
 key = IoSbmtProductFeaturesKey(product_sku=15052004)
 cursor = cache.scan(partitions=1)

 # Uncomment to see error
 # value = cache.get(key)

 true_key, true_value = next(cursor)  # THIS LINE IS CRUCIAL!!!11
 print("true_key:  ", true_key)
 print("true_value:", true_value)

 value = cache.get(key)


 So if data from cursor is read first then everything works as expected.
 If there is no cursor or reading data from it happens AFTER
 cache.get(key) - everything fails and key is not found.

 Is it ok?
 Maybe there is some dynamic binding of classes?
 Looks really weird.

 Help please!

 On 20 Dec 2022, at 1:35 PM, Айсина Роза Мунеровна <
 roza.ays...@sbermarket.ru> wrote:

 Hola!
 I can’t get data by key in Python in caches created in Java with binary
 object

Re: [!!Массовая рассылка]Can't access binary key from Python client

2022-12-22 Thread Айсина Роза Мунеровна

Oh, should I enable compact footer flag in thin client that actually creates 
caches in our cluster?

Like this

final ClientConfiguration cfg = new ClientConfiguration()
.setAddresses(addresses)
.setBinaryConfiguration(new BinaryConfiguration().setCompactFooter(true));
?

Thanks!

On 22 Dec 2022, at 12:20 PM, Айсина Роза Мунеровна  
wrote:

Hi Ivan!

Thank you for your reply!

I tested your snippets with client and server node.
When I raise server node in the snippet - everything works as expected, the 
same output (key exists).
When I raise cluster manually on localhost and raise client node in the snippet 
- I have None in output.

I used this dependency:
pyignite = "0.5.2”  in Python
implementation group: 'org.apache.ignite', name: 'ignite-core', version: 
‘2.13.0’ in Java

The same version that we have for production cluster.

So how can I fix this? And where - in Python connection or server config?

Thanks!


On 22 Dec 2022, at 10:40 AM, Ivan Daschinsky  wrote:

Внимание: Внешний отправитель!
Если вы не знаете отправителя - не открывайте вложения, не переходите по 
ссылкам, не пересылайте письмо!

Firstly, please run the java snippet, then run the python snippet
I got this output:
/home/ivandasch/.virtualenvs/pyignite-py38/bin/python 
/home/ivandasch/.config/JetBrains/PyCharm2022.2/scratches/scratch.py
ValueType(name='test', version=1)

чт, 22 дек. 2022 г. в 10:40, Ivan Daschinsky 
mailto:ivanda...@gmail.com>>:
Just tried on (ignite 2.13.0 server, ignite-client on master, pyignite on 0.6.0)

Java code:

import org.apache.ignite.Ignition;
import org.apache.ignite.binary.BinaryObject;
import org.apache.ignite.client.ClientCache;
import org.apache.ignite.client.IgniteClient;
import org.apache.ignite.configuration.ClientConfiguration;

class Scratch {
public static void main(String[] args) {
try (IgniteClient client = Ignition.startClient(new 
ClientConfiguration()
.setAddresses("127.0.0.1:10800", 
"127.0.0.1:10801", 
"127.0.0.1:10802"))) {

ClientCache cache = 
client.getOrCreateCache("test").withKeepBinary();

BinaryObject key = 
client.binary().builder("KeyType").setField("id", 10, Integer.class).build();
BinaryObject val = 
client.binary().builder("ValueType").setField("name", "test", 
String.class).build();

cache.put(key, val);
}
}
}

Python code:

from pyignite import Client
from pyignite import GenericObjectMeta
from pyignite.datatypes import IntObject, String

class Key(
metaclass=GenericObjectMeta,
type_name="KeyType",
schema={
'id': IntObject,
},
version=1,
):
pass

class Value(
metaclass=GenericObjectMeta,
type_name="ValueType",
schema={
'name': String,
},
version=1,
):
pass

client = Client()
client.connect([('127.0.0.1', 10800 + i) for i in range(0, 3)])
cache = client.get_or_create_cache("test")

print(cache.get(Key(id=10)))

Everything works as expected.

I guess that you used the version of ignite-core (thin-client) older than 
2.14.0.
In that version, compactFooter equals to false, but on server side and pyignite 
it is by default enabled.

But pyignite has an ability to detect this param after fetching the data. That 
is the reason why you code started working after fetching few data by a scan 
query.

чт, 22 дек. 2022 г. в 09:13, Ivan Daschinsky 
mailto:ivanda...@gmail.com>>:
Couls you please specify the exact versions of pyignite and ignite-core (java 
thin client)?

ср, 21 дек. 2022 г., 18:36 Айсина Роза Мунеровна 
mailto:roza.ays...@sbermarket.ru>>:
Hola again!

I accidently discovered some strange behaviour when trying to get value by key 
in Python.

I do this in part 3:


cache = ignite_client.get_cache("PUBLIC_ProductFeatures")
key = IoSbmtProductFeaturesKey(product_sku=15052004)
cursor = cache.scan(partitions=1)

# Uncomment to see error
# value = cache.get(key)

true_key, true_value = next(cursor)  # THIS LINE IS CRUCIAL!!!11
print("true_key:  ", true_key)
print("true_value:", true_value)

value = cache.get(key)

So if data from cursor is read first then everything works as expected.
If there is no cursor or reading data from it happens AFTER cache.get(key) - 
everything fails and key is not found.

Is it ok?
Maybe there is some dynamic binding of classes?
Looks really weird.

Help please!

On 20 Dec 2022, at 1:35 PM, Айсина Роза Мунеровна 
mailto:roza.ays...@sbermarket.ru>> wrote:

Hola!
I can’t get data by key in Python in caches created in Java with binary objects.

1. Cache was created though DDL in SQL API:

CREATE TABLE IF NOT EXISTS PUBLIC.ProductFeatures
(
 product_sku INT PRIMARY KEY,
 total_cnt_orders_with_sku INT
)
WITH "CACHE_NAME=PUBLIC_ProductFeatures,
 KEY_TYPE=io.sbmt.ProductFeaturesKey,
 VALUE_TYPE=io.sbmt.ProductFeaturesValue,
 AFFINITY_KEY=product_sku,
 TEMPLATE=PARTITIONED,
 BACKUPS=1”

2. Java apps up

Re: How to use Hash Join in SQL API?

2022-12-22 Thread Айсина Роза Мунеровна

Hi!

Thank you for your replies!

I tried to specify any index except primary key index and explained showed, 
that SCAN is used which, I guess, is full table scan:


explain
SELECT ProductFeatures.product_sku,
   ProductFeatures.total_cnt_orders_with_sku,
   RetailerProductFeatures.mean_daily_sku_retailer_popularity
FROM ProductFeatures
 LEFT JOIN RetailerProductFeatures USE INDEX(PUBLIC."_key_PK_hash")
   ON ProductFeatures.product_sku = 
RetailerProductFeatures.product_sku
   AND RetailerProductFeatures.retailer_id = 142
WHERE ProductFeatures.product_sku IN (52864, 1582957, 110319, 1477711, 272024)
;

SELECT
__Z0.PRODUCT_SKU AS __C0_0,
__Z0.TOTAL_CNT_ORDERS_WITH_SKU AS __C0_1,
__Z1.MEAN_DAILY_SKU_RETAILER_POPULARITY AS __C0_2
FROM PUBLIC.PRODUCTFEATURES __Z0
/* PUBLIC."_key_PK": PRODUCT_SKU IN(52864, 1582957, 110319, 1477711, 
272024) */
/* WHERE __Z0.PRODUCT_SKU IN(52864, 1582957, 110319, 1477711, 272024)
*/
LEFT OUTER JOIN PUBLIC.RETAILERPRODUCTFEATURES __Z1 USE INDEX ("_key_PK_hash")
/* PUBLIC.RETAILERPRODUCTFEATURES.__SCAN_ */
ON (__Z1.RETAILER_ID = 142)
AND (__Z0.PRODUCT_SKU = __Z1.PRODUCT_SKU)
WHERE __Z0.PRODUCT_SKU IN(52864, 1582957, 110319, 1477711, 272024)

So I guess there is no way to specify more “fast” index because the main goal 
is to speed up our JOIN queries.

Thanks!

On 21 Dec 2022, at 9:06 PM, Николай Ижиков  wrote:

Hello.

It seems, you should replace `HASH_JOIN_IDX` with your actual index name.
You can find all indexes with `SELECT * FROM SYS.INDEXES`

21 дек. 2022 г., в 20:43, Stephen Darlington  
написал(а):

I don’t think it’s ever been in Ignite.

On 21 Dec 2022, at 16:49, Айсина Роза Мунеровна 
mailto:roza.ays...@sbermarket.ru>> wrote:

Hi Stephen!

Sorry, I forgot to attach link on doc:
https://ignite.apache.org/docs/2.11.1/SQL/distributed-joins#hash-joins

We use 2.13.0 Ignite version.
So this feature was deleted from releases after 2.11? :(

On 21 Dec 2022, at 7:43 PM, Stephen Darlington 
mailto:stephen.darling...@gridgain.com>> wrote:

Внимание: Внешний отправитель!
Если вы не знаете отправителя - не открывайте вложения, не переходите по 
ссылкам, не пересылайте письмо!

Where did you get that syntax from? I don’t think Ignite supports hash joins, 
though there are other distributions of Ignite that do.

On 21 Dec 2022, at 16:22, Айсина Роза Мунеровна 
mailto:roza.ays...@sbermarket.ru>> wrote:

Hola again!

I have a problem when trying to use Hah Join in SQL API.
I am using this doc:

What I am doing:


query = """
SELECT pf.product_sku,
   pf.total_cnt_orders_with_sku,
   rpf.mean_daily_sku_retailer_popularity
FROM ProductFeatures AS pf
 LEFT JOIN RetailerProductFeatures AS rpf
USE INDEX(HASH_JOIN_IDX)
   ON pf.product_sku = rpf.product_sku
   AND rpf.retailer_id = 142
WHERE pf.product_sku IN (52864, 1582957, 110319, 1477711, 272024)
"""

data = next(
ignite_client.sql(
query,
distributed_joins=False,
enforce_join_order=True,
collocated=True,
)
)

What I get:
Index "HASH_JOIN_IDX" not found


So basically it is simple join SQL query that works fine without hash join 
index.
Both tables have affinity key product_sku and this column is part of primary 
key.

When I look at index system tables I see that there is _key_PK_hash index for 
both tables
But I had no luck to specify it - SQL parser can’t find it either.

Please help!
--

Роза Айсина
Старший разработчик ПО
СберМаркет | Доставка из любимых магазинов



Email: roza.ays...@sbermarket.ru
Mob:
Web: sbermarket.ru
App: 
iOS
 и 
Android







УВЕДОМЛЕНИЕ О КОНФИДЕНЦИАЛЬНОСТИ: это электронное сообщение и любые документы, 
приложенные к нему, содержат конфиденциальную информацию. Настоящим уведомляем 
Вас о том, что, если это сообщение не предназначено Вам, использование, 
копирование, распространение информации, содержащейся в настоящем сообщении, а 
также осуществление любых действий на основе этой информации, строго запрещено. 
Если Вы получили это сообщение по ошибке, пожалуйста, сообщите об этом 
отправителю по электронной почте и удалите это сообщение.
CONFIDENTIALITY NOTICE: This email and any files attached to it are 
confidential. If you are not the intended recipient you are notified that 
using, copying, distributing or taking any action in reliance on the contents 
of this information is strictly prohibited. If you have received this email in 
error please notify the sender and delete this email.


--

Роза Айсина
Старший разработчик ПО
СберМаркет | Доставка из любимых магазинов



Email: r

Re: [!!Массовая рассылка]Can't access binary key from Python client

2022-12-22 Thread Айсина Роза Мунеровна

Hi Ivan!

Thank you for your reply!

I tested your snippets with client and server node.
When I raise server node in the snippet - everything works as expected, the 
same output (key exists).
When I raise cluster manually on localhost and raise client node in the snippet 
- I have None in output.

I used this dependency:
pyignite = "0.5.2”  in Python
implementation group: 'org.apache.ignite', name: 'ignite-core', version: 
‘2.13.0’ in Java

The same version that we have for production cluster.

So how can I fix this? And where - in Python connection or server config?

Thanks!


On 22 Dec 2022, at 10:40 AM, Ivan Daschinsky  wrote:

Внимание: Внешний отправитель!
Если вы не знаете отправителя - не открывайте вложения, не переходите по 
ссылкам, не пересылайте письмо!

Firstly, please run the java snippet, then run the python snippet
I got this output:
/home/ivandasch/.virtualenvs/pyignite-py38/bin/python 
/home/ivandasch/.config/JetBrains/PyCharm2022.2/scratches/scratch.py
ValueType(name='test', version=1)

чт, 22 дек. 2022 г. в 10:40, Ivan Daschinsky 
mailto:ivanda...@gmail.com>>:
Just tried on (ignite 2.13.0 server, ignite-client on master, pyignite on 0.6.0)

Java code:

import org.apache.ignite.Ignition;
import org.apache.ignite.binary.BinaryObject;
import org.apache.ignite.client.ClientCache;
import org.apache.ignite.client.IgniteClient;
import org.apache.ignite.configuration.ClientConfiguration;

class Scratch {
public static void main(String[] args) {
try (IgniteClient client = Ignition.startClient(new 
ClientConfiguration()
.setAddresses("127.0.0.1:10800", 
"127.0.0.1:10801", 
"127.0.0.1:10802"))) {

ClientCache cache = 
client.getOrCreateCache("test").withKeepBinary();

BinaryObject key = 
client.binary().builder("KeyType").setField("id", 10, Integer.class).build();
BinaryObject val = 
client.binary().builder("ValueType").setField("name", "test", 
String.class).build();

cache.put(key, val);
}
}
}

Python code:

from pyignite import Client
from pyignite import GenericObjectMeta
from pyignite.datatypes import IntObject, String

class Key(
metaclass=GenericObjectMeta,
type_name="KeyType",
schema={
'id': IntObject,
},
version=1,
):
pass

class Value(
metaclass=GenericObjectMeta,
type_name="ValueType",
schema={
'name': String,
},
version=1,
):
pass

client = Client()
client.connect([('127.0.0.1', 10800 + i) for i in range(0, 3)])
cache = client.get_or_create_cache("test")

print(cache.get(Key(id=10)))

Everything works as expected.

I guess that you used the version of ignite-core (thin-client) older than 
2.14.0.
In that version, compactFooter equals to false, but on server side and pyignite 
it is by default enabled.

But pyignite has an ability to detect this param after fetching the data. That 
is the reason why you code started working after fetching few data by a scan 
query.

чт, 22 дек. 2022 г. в 09:13, Ivan Daschinsky 
mailto:ivanda...@gmail.com>>:
Couls you please specify the exact versions of pyignite and ignite-core (java 
thin client)?

ср, 21 дек. 2022 г., 18:36 Айсина Роза Мунеровна 
mailto:roza.ays...@sbermarket.ru>>:
Hola again!

I accidently discovered some strange behaviour when trying to get value by key 
in Python.

I do this in part 3:


cache = ignite_client.get_cache("PUBLIC_ProductFeatures")
key = IoSbmtProductFeaturesKey(product_sku=15052004)
cursor = cache.scan(partitions=1)

# Uncomment to see error
# value = cache.get(key)

true_key, true_value = next(cursor)  # THIS LINE IS CRUCIAL!!!11
print("true_key:  ", true_key)
print("true_value:", true_value)

value = cache.get(key)

So if data from cursor is read first then everything works as expected.
If there is no cursor or reading data from it happens AFTER cache.get(key) - 
everything fails and key is not found.

Is it ok?
Maybe there is some dynamic binding of classes?
Looks really weird.

Help please!

On 20 Dec 2022, at 1:35 PM, Айсина Роза Мунеровна 
mailto:roza.ays...@sbermarket.ru>> wrote:

Hola!
I can’t get data by key in Python in caches created in Java with binary objects.

1. Cache was created though DDL in SQL API:

CREATE TABLE IF NOT EXISTS PUBLIC.ProductFeatures
(
 product_sku INT PRIMARY KEY,
 total_cnt_orders_with_sku INT
)
WITH "CACHE_NAME=PUBLIC_ProductFeatures,
 KEY_TYPE=io.sbmt.ProductFeaturesKey,
 VALUE_TYPE=io.sbmt.ProductFeaturesValue,
 AFFINITY_KEY=product_sku,
 TEMPLATE=PARTITIONED,
 BACKUPS=1”

2. Java apps uploads data to this cache through Key-Value API with binary 
object underneath:

ClientCache igniteCache = igniteClient
 .cache(config.getCacheName())
 .withKeepBinary();

final BinaryObjectBuilder keyBuilder = 
igniteClient.binary().builder(config.getKeyType());
final BinaryObjectBuilder valueBuilder = 
igniteClient.binary().builder(config.ge

DataRegion not releasing memory back to OS

Issues with using deployment when deploying Ignite on K8S

Re: [!!Массовая рассылка]Can't access binary key from Python client

Re: How to use Hash Join in SQL API?

Re: How to use Hash Join in SQL API?

Re: [!!Массовая рассылка]Can't access binary key from Python client

Re: Read from backup with PRIMARY_SYNC

Re: [!!Массовая рассылка]Can't access binary key from Python client

Re: [!!Массовая рассылка]Can't access binary key from Python client

Re: How to use Hash Join in SQL API?

Re: [!!Массовая рассылка]Can't access binary key from Python client

Re: [!!Массовая рассылка]Can't access binary key from Python client

Re: [!!Массовая рассылка]Can't access binary key from Python client

Re: How to use Hash Join in SQL API?

Re: [!!Массовая рассылка]Can't access binary key from Python client

15 matches

Site Navigation

Mail list logo

Footer information