Yeap!
I'll start implementing it next week.
I think I'll create new jobs and when everything is OK — will switch settings
in template to new chain.
It will take some time to do everything right though.
> On 5 Mar 2021, at 09:28, Maksim Timonin wrote:
>
> Hi, Petr!
>
> I've created a ticket
Ilya Kasnacheev created IGNITE-14284:
Summary: sqlline: `Property "url" is required'
Key: IGNITE-14284
URL: https://issues.apache.org/jira/browse/IGNITE-14284
Project: Ignite
Issue Type:
Ilya Kasnacheev created IGNITE-14285:
Summary: sqllline: `Bad history file syntax!'
Key: IGNITE-14285
URL: https://issues.apache.org/jira/browse/IGNITE-14285
Project: Ignite
Issue Type: B
Pavel,
I've checked the IEP and I like it. The only thing that seems a bit
confusing to me
is that there are 4 different variants for clients but there are cons and
pros for
different variants. Maybe at least few sentences should be written here to
give developers who are not familiar with DataStr
Igor,
As per our private conversation, I'll try to provide some perf measurements
for those 4 variants, and more detailed descriptions too.
Thanks!
On Fri, Mar 5, 2021 at 12:55 PM Igor Sapego wrote:
> Pavel,
>
> I've checked the IEP and I like it. The only thing that seems a bit
> confusing to
Hello!
-1 (binding)
I have faced two sqlline issues in 30 seconds, of which one is mostly
cosmetic while the other is very annoying:
https://issues.apache.org/jira/browse/IGNITE-14284
https://issues.apache.org/jira/browse/IGNITE-14285
Since the new sqlline uses different history file format but
+1 (binding)
Checked C++ compilation, C++ examples
Best Regards,
Igor
On Fri, Mar 5, 2021 at 12:32 AM Denis Magda wrote:
> +1 (binding)
>
> Downloaded the binary package and started a 2-node cluster on MacOS with
> ignite.sh.
>
> -
> Denis
>
>
> On Wed, Mar 3, 2021 at 1:03 PM Maxim Muzafarov
Pavel, thank you for your effort.
BTW, are you sure that receiver should be a param of STREAMER_START_REQUEST?
Receiver is mostly internal stuff and I can hardly imagine why
someone would decide to change defaults.
пт, 5 мар. 2021 г. в 13:01, Pavel Tupitsyn :
> Igor,
>
> As per our private conve
IMHO, also STREAMER_FLUSH_REQUEST should be added too. Client can flush
large batches instead of closing resource.
IMHO this is preferable than creating streamer per batch.
пт, 5 мар. 2021 г. в 14:48, Ivan Daschinsky :
> Pavel, thank you for your effort.
>
> BTW, are you sure that receiver should
Hello!
Please run tests against this change, get a green TC visa for the ticket.
Regards,
--
Ilya Kasnacheev
ср, 3 мар. 2021 г. в 17:13, Atri Sharma :
> Hi,
>
> Please help review this PR:
>
> https://github.com/apache/ignite/pull/8845
>
> Regards,
>
> Atri
>
Ivan,
> Receiver is mostly internal stuff
StreamReceiver is public API [1]
> STREAMER_FLUSH_REQUEST should be added too
Both proposed requests have a Flush flag - please see Details sections in
the IEP.
When user code calls client-side Flush method, we send the current
client-side batch with that
>> Both proposed requests have a Flush flag - please see Details sections
in the IEP.
Ok, sorry, I missed this.
>> StreamReceiver is public API [1]
I know it. But this "object" should contains custom logic for putting data
in cache. How do you suggests to serialize this object?
Implement custom cla
I also suppose, that closing should be done wia OP_RESOURCE_CLOSE. It'is
more consistent and resembles with existing cursor api.
пт, 5 мар. 2021 г. в 15:37, Ivan Daschinsky :
> >> Both proposed requests have a Flush flag - please see Details sections
> in the IEP.
> Ok, sorry, I missed this.
> >>
> How do you suggests to serialize this object?
Like a normal binary object. This scenario already exists for ScanQuery and
ContinuousQuery filters.
- It works for Java and .NET; potentially for other platforms
- Corresponding types should exist on server nodes
E.g. if a Java class `MyFilter { St
>>> - Corresponding types should exist on server nodes
Ok, but I suppose this is of questional usability, same for existing
implementation for ScanQuery and ContinousQuery.
For queries it's probably ok to add some custom filters and put them in
servers' classpathes, but I can hardly imagine
somebod
Hi Nikolay, can you do a review?
02.03.2021, 18:59, "Nikolay Izhikov" :
> +1 For this.
>
>> 2 марта 2021 г., в 18:32, ткаленко кирилл написал(а):
>>
>> Hi, Nikolay!
>>
>> I thought about your proposal and offer the following two metrics:
>>
>> 1)The number of bytes logged to the WAL;
>> 2)Th
Yes, definitely.
> 5 марта 2021 г., в 16:31, ткаленко кирилл написал(а):
>
> Hi Nikolay, can you do a review?
>
> 02.03.2021, 18:59, "Nikolay Izhikov" :
>> +1 For this.
>>
>>> 2 марта 2021 г., в 18:32, ткаленко кирилл
>>> написал(а):
>>>
>>> Hi, Nikolay!
>>>
>>> I thought about your pro
> I suppose this is of questional usability, same for existing
> implementation for ScanQuery and ContinousQuery
One way or another, we need to be able to run custom logic
on the server side from thin clients.
Our current direction can be seen as "Java is our DSL":
write server-side logic in Java
I suppose, that the best variantl -- custom DSL similar to MongoDB query
language.
I understand that implementing this is much harder, but users want this
variant.
пт, 5 мар. 2021 г. в 16:52, Pavel Tupitsyn :
> > I suppose this is of questional usability, same for existing
> > implementation for
> custom DSL
This is a topic for 3.0 - would you like to start a separate thread?
On Fri, Mar 5, 2021 at 4:54 PM Ivan Daschinsky wrote:
> I suppose, that the best variantl -- custom DSL similar to MongoDB query
> language.
> I understand that implementing this is much harder, but users want this
Agree, this is completely offtopic here.
пт, 5 мар. 2021 г. в 17:02, Pavel Tupitsyn :
> > custom DSL
> This is a topic for 3.0 - would you like to start a separate thread?
>
> On Fri, Mar 5, 2021 at 4:54 PM Ivan Daschinsky
> wrote:
>
> > I suppose, that the best variantl -- custom DSL similar to
Pavel,
IEP looks good to me overall. I have only one concern: currently, for thick
client "add" method we return the future which completes when the current
batch is actually added to the cache, even if "flush" method is not invoked
explicitly. For thin client with the proposed protocol we can't p
Hi Igniters,
I've detected some new issue on TeamCity to be handled. You are more than
welcomed to help.
If your changes can lead to this failure(s): We're grateful that you were a
volunteer to make the contribution to this project, but things change and you
may no longer be able to finalize
Ignites,
I've created the IEP-69 [1] which describes the evolutionary release
process for the Apache Ignite 2.x version. You can find all the
details of my suggestion there, but here you can find the crucial
points:
0. Versioning - grand.major.bug-fix[-rc_number]
1. Prepare the next 3.0 release
Hi Igniters,
I've detected some new issue on TeamCity to be handled. You are more than
welcomed to help.
*New Critical Failure in master Control Utility
https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_ControlUtility?branch=%3Cdefault%3E
No changes in the build
Hi Igniters,
I've detected some new issue on TeamCity to be handled. You are more than
welcomed to help.
If your changes can lead to this failure(s): We're grateful that you were a
volunteer to make the contribution to this project, but things change and you
may no longer be able to finalize
26 matches
Mail list logo