22.02.2015 15:10, Mark Rotteveel wrote:
> I am reimplementing the event handling in Jaybird, and the current (old)
> implementation on the asynchronous port (event connection) processes the
> operations:
>
> op_dummy, op_exit, op_disconnect, op_event and op_response
>
> I'd like to know two things
22.02.2015 20:19, Slavomir Skopalik wrote:
>
> I was made litle improovement in record level compresion.
>
> Motivation:
> - significant dabase grow increase after switch to UTF8
>
> Analysis:
> - I was found inefficient algoritmus for compressing zeroes
> - I was found, that some control char va
22.02.2015 19:11, Adriano dos Santos Fernandes wrote:
> A solution must be to pass a parameter to destroy methods specifying if
> they should release or not the object.
More dragon poker - more fun.
> And of course, all implementations should follow it.
>
> So with or without smart pointers, u
On 22-02-2015 14:51, Dimitry Sibiryakov wrote:
> 22.02.2015 18:35, Adriano dos Santos Fernandes wrote:
>> So you have:
>>
>> IBlob* blob = ...->openBlob(...);
>> blob->cancel();
>> // no leak
>
>Using of smart pointers here makes life even funnier. IMHO, it is Y-valve
> bug.
>But in absen
22.02.2015 18:35, Adriano dos Santos Fernandes wrote:
> So you have:
>
> IBlob* blob = ...->openBlob(...);
> blob->cancel();
> // no leak
Using of smart pointers here makes life even funnier. IMHO, it is Y-valve
bug.
But in absence of API specifications it is rather "as expected".
--
W
Hi!
Lets call YBlob::cancel, YTransaction::commit, YTransaction::rollback,
YEvents::cancel and maybe others as "destroy methods".
Destroy methods when called in y-valve objects automatically does a
"release" on them.
So you have:
IBlob* blob = ...->openBlob(...);
blob->cancel();
// no leak
On
Hi all,
I was made litle improovement in record level compresion.
Motivation:
- significant dabase grow increase after switch to UTF8
Analysis:
- I was found inefficient algoritmus for compressing zeroes
- I was found, that some control char values are not used
Solution:
- I add to code abili
I am reimplementing the event handling in Jaybird, and the current (old)
implementation on the asynchronous port (event connection) processes the
operations:
op_dummy, op_exit, op_disconnect, op_event and op_response
I'd like to know two things:
1) Is it indeed possible that op_response is sent
No need to flush dirty pages to disk after creation of temporary table index
Key: CORE-4696
URL: http://tracker.firebirdsql.org/browse/CORE-4696
Project: Firebird Core
