Re: Seconds and milliseconds confusion in python thin client
I have a compromise variant. 1. Large timeouts are set usually only for expire_policy. I suggest to support datetime.timedelta here and int as milliseconds 2. All others timeouts should accept only ints as milliseconds. 3. Only timeout in Connection as sockettimeout should remain float in seconds, because it corresponds to socket.settimeout method in python (accepts floating point number) This is a compromise between usability and backward compatibility WDYT? ср, 16 июн. 2021 г. в 11:09, Ivan Daschinsky : > > I've created ticket for it https://issues.apache.org/jira/browse/IGNITE-14911 > > ср, 16 июн. 2021 г. в 08:37, Ivan Daschinsky : > > > > Ops, i don't even know about it. I believe that this is so rarely used, i > > don't even noticed it. I am talking about transactions and expiry policy. I > > suppose that in the case of sql we can simply change it. > > > > ср, 16 июн. 2021 г., 00:46 Igor Sapego : > >> > >> Why is it not released? > >> > >> I can see client.sql(timeout) in 0.4.0 for example, which is int number of > >> ms. > >> > >> Best Regards, > >> Igor > >> > >> > >> On Tue, Jun 15, 2021 at 11:52 PM Ivan Daschinsky > >> wrote: > >> > >> > BTW, common approach is to treat both ints and floats as seconds. Floats > >> > are used to set timeout with millisecods precision. I.e. > >> > asyncio.sleep(1.0) > >> > and asyncio.sleep(1) pauses coroutine for 1 sec. Lets create ticket for > >> > it, > >> > stop voting for 0.5.0.rc0 and schedule next vote. > >> > > >> > вт, 15 июн. 2021 г., 23:49 Ivan Daschinsky : > >> > > >> > > Igor, I suppose that you are probably right. But there is no need to > >> > > notice or deprecate something. This functionality is not released yet > >> > > > >> > > вт, 15 июн. 2021 г., 23:41 Igor Sapego : > >> > > > >> > >> Hi Igniters, > >> > >> > >> > >> I've noticed a weird behaviour of python thin client. In those places > >> > >> where > >> > >> we have > >> > >> timeouts or any other parameters that take time in some places we > >> > >> treat > >> > it > >> > >> like integer > >> > >> number of milliseconds, in others it can take both floats (as a number > >> > of > >> > >> seconds) > >> > >> and ints (number of milliseconds). This approach looks very confusing > >> > >> to > >> > >> me > >> > >> as > >> > >> it leads to things where tx_start(1) and tx_start(1.0) are not > >> > >> actually > >> > >> the > >> > >> same thing. > >> > >> > >> > >> AFAIK in python the most common way to pass time to such functions is > >> > >> to > >> > >> use floats > >> > >> as a number of seconds. This is the approach I propose to use in our > >> > >> API > >> > >> as > >> > >> well. Let's > >> > >> deprecate usage of ints in those functions with the appropriate > >> > >> warning > >> > >> before getting rid > >> > >> of it. > >> > >> > >> > >> What do you think? > >> > >> > >> > >> Best Regards, > >> > >> Igor > >> > >> > >> > > > >> > > > > > -- > Sincerely yours, Ivan Daschinskiy -- Sincerely yours, Ivan Daschinskiy
Re: Seconds and milliseconds confusion in python thin client
I've created ticket for it https://issues.apache.org/jira/browse/IGNITE-14911 ср, 16 июн. 2021 г. в 08:37, Ivan Daschinsky : > > Ops, i don't even know about it. I believe that this is so rarely used, i > don't even noticed it. I am talking about transactions and expiry policy. I > suppose that in the case of sql we can simply change it. > > ср, 16 июн. 2021 г., 00:46 Igor Sapego : >> >> Why is it not released? >> >> I can see client.sql(timeout) in 0.4.0 for example, which is int number of >> ms. >> >> Best Regards, >> Igor >> >> >> On Tue, Jun 15, 2021 at 11:52 PM Ivan Daschinsky >> wrote: >> >> > BTW, common approach is to treat both ints and floats as seconds. Floats >> > are used to set timeout with millisecods precision. I.e. asyncio.sleep(1.0) >> > and asyncio.sleep(1) pauses coroutine for 1 sec. Lets create ticket for it, >> > stop voting for 0.5.0.rc0 and schedule next vote. >> > >> > вт, 15 июн. 2021 г., 23:49 Ivan Daschinsky : >> > >> > > Igor, I suppose that you are probably right. But there is no need to >> > > notice or deprecate something. This functionality is not released yet >> > > >> > > вт, 15 июн. 2021 г., 23:41 Igor Sapego : >> > > >> > >> Hi Igniters, >> > >> >> > >> I've noticed a weird behaviour of python thin client. In those places >> > >> where >> > >> we have >> > >> timeouts or any other parameters that take time in some places we treat >> > it >> > >> like integer >> > >> number of milliseconds, in others it can take both floats (as a number >> > of >> > >> seconds) >> > >> and ints (number of milliseconds). This approach looks very confusing to >> > >> me >> > >> as >> > >> it leads to things where tx_start(1) and tx_start(1.0) are not actually >> > >> the >> > >> same thing. >> > >> >> > >> AFAIK in python the most common way to pass time to such functions is to >> > >> use floats >> > >> as a number of seconds. This is the approach I propose to use in our API >> > >> as >> > >> well. Let's >> > >> deprecate usage of ints in those functions with the appropriate warning >> > >> before getting rid >> > >> of it. >> > >> >> > >> What do you think? >> > >> >> > >> Best Regards, >> > >> Igor >> > >> >> > > >> > -- Sincerely yours, Ivan Daschinskiy
Re: Seconds and milliseconds confusion in python thin client
Ops, i don't even know about it. I believe that this is so rarely used, i don't even noticed it. I am talking about transactions and expiry policy. I suppose that in the case of sql we can simply change it. ср, 16 июн. 2021 г., 00:46 Igor Sapego : > Why is it not released? > > I can see client.sql(timeout) in 0.4.0 for example, which is int number of > ms. > > Best Regards, > Igor > > > On Tue, Jun 15, 2021 at 11:52 PM Ivan Daschinsky > wrote: > > > BTW, common approach is to treat both ints and floats as seconds. Floats > > are used to set timeout with millisecods precision. I.e. > asyncio.sleep(1.0) > > and asyncio.sleep(1) pauses coroutine for 1 sec. Lets create ticket for > it, > > stop voting for 0.5.0.rc0 and schedule next vote. > > > > вт, 15 июн. 2021 г., 23:49 Ivan Daschinsky : > > > > > Igor, I suppose that you are probably right. But there is no need to > > > notice or deprecate something. This functionality is not released yet > > > > > > вт, 15 июн. 2021 г., 23:41 Igor Sapego : > > > > > >> Hi Igniters, > > >> > > >> I've noticed a weird behaviour of python thin client. In those places > > >> where > > >> we have > > >> timeouts or any other parameters that take time in some places we > treat > > it > > >> like integer > > >> number of milliseconds, in others it can take both floats (as a number > > of > > >> seconds) > > >> and ints (number of milliseconds). This approach looks very confusing > to > > >> me > > >> as > > >> it leads to things where tx_start(1) and tx_start(1.0) are not > actually > > >> the > > >> same thing. > > >> > > >> AFAIK in python the most common way to pass time to such functions is > to > > >> use floats > > >> as a number of seconds. This is the approach I propose to use in our > API > > >> as > > >> well. Let's > > >> deprecate usage of ints in those functions with the appropriate > warning > > >> before getting rid > > >> of it. > > >> > > >> What do you think? > > >> > > >> Best Regards, > > >> Igor > > >> > > > > > >
Re: Seconds and milliseconds confusion in python thin client
Why is it not released? I can see client.sql(timeout) in 0.4.0 for example, which is int number of ms. Best Regards, Igor On Tue, Jun 15, 2021 at 11:52 PM Ivan Daschinsky wrote: > BTW, common approach is to treat both ints and floats as seconds. Floats > are used to set timeout with millisecods precision. I.e. asyncio.sleep(1.0) > and asyncio.sleep(1) pauses coroutine for 1 sec. Lets create ticket for it, > stop voting for 0.5.0.rc0 and schedule next vote. > > вт, 15 июн. 2021 г., 23:49 Ivan Daschinsky : > > > Igor, I suppose that you are probably right. But there is no need to > > notice or deprecate something. This functionality is not released yet > > > > вт, 15 июн. 2021 г., 23:41 Igor Sapego : > > > >> Hi Igniters, > >> > >> I've noticed a weird behaviour of python thin client. In those places > >> where > >> we have > >> timeouts or any other parameters that take time in some places we treat > it > >> like integer > >> number of milliseconds, in others it can take both floats (as a number > of > >> seconds) > >> and ints (number of milliseconds). This approach looks very confusing to > >> me > >> as > >> it leads to things where tx_start(1) and tx_start(1.0) are not actually > >> the > >> same thing. > >> > >> AFAIK in python the most common way to pass time to such functions is to > >> use floats > >> as a number of seconds. This is the approach I propose to use in our API > >> as > >> well. Let's > >> deprecate usage of ints in those functions with the appropriate warning > >> before getting rid > >> of it. > >> > >> What do you think? > >> > >> Best Regards, > >> Igor > >> > > >
Re: Seconds and milliseconds confusion in python thin client
BTW, common approach is to treat both ints and floats as seconds. Floats are used to set timeout with millisecods precision. I.e. asyncio.sleep(1.0) and asyncio.sleep(1) pauses coroutine for 1 sec. Lets create ticket for it, stop voting for 0.5.0.rc0 and schedule next vote. вт, 15 июн. 2021 г., 23:49 Ivan Daschinsky : > Igor, I suppose that you are probably right. But there is no need to > notice or deprecate something. This functionality is not released yet > > вт, 15 июн. 2021 г., 23:41 Igor Sapego : > >> Hi Igniters, >> >> I've noticed a weird behaviour of python thin client. In those places >> where >> we have >> timeouts or any other parameters that take time in some places we treat it >> like integer >> number of milliseconds, in others it can take both floats (as a number of >> seconds) >> and ints (number of milliseconds). This approach looks very confusing to >> me >> as >> it leads to things where tx_start(1) and tx_start(1.0) are not actually >> the >> same thing. >> >> AFAIK in python the most common way to pass time to such functions is to >> use floats >> as a number of seconds. This is the approach I propose to use in our API >> as >> well. Let's >> deprecate usage of ints in those functions with the appropriate warning >> before getting rid >> of it. >> >> What do you think? >> >> Best Regards, >> Igor >> >
Re: Seconds and milliseconds confusion in python thin client
Igor, I suppose that you are probably right. But there is no need to notice or deprecate something. This functionality is not released yet вт, 15 июн. 2021 г., 23:41 Igor Sapego : > Hi Igniters, > > I've noticed a weird behaviour of python thin client. In those places where > we have > timeouts or any other parameters that take time in some places we treat it > like integer > number of milliseconds, in others it can take both floats (as a number of > seconds) > and ints (number of milliseconds). This approach looks very confusing to me > as > it leads to things where tx_start(1) and tx_start(1.0) are not actually the > same thing. > > AFAIK in python the most common way to pass time to such functions is to > use floats > as a number of seconds. This is the approach I propose to use in our API as > well. Let's > deprecate usage of ints in those functions with the appropriate warning > before getting rid > of it. > > What do you think? > > Best Regards, > Igor >
Seconds and milliseconds confusion in python thin client
Hi Igniters, I've noticed a weird behaviour of python thin client. In those places where we have timeouts or any other parameters that take time in some places we treat it like integer number of milliseconds, in others it can take both floats (as a number of seconds) and ints (number of milliseconds). This approach looks very confusing to me as it leads to things where tx_start(1) and tx_start(1.0) are not actually the same thing. AFAIK in python the most common way to pass time to such functions is to use floats as a number of seconds. This is the approach I propose to use in our API as well. Let's deprecate usage of ints in those functions with the appropriate warning before getting rid of it. What do you think? Best Regards, Igor