Minor performance optimization - avoid additional database attachment from
security objects mapping code
Key: CORE-5433
URL: http://tracker.firebirdsql.org/br
30.12.2016 18:05, Dimitry Sibiryakov wrote:
> Do anybody object if I try to dig a little into CORE-5064?
No, feel free.
Dmitry
--
Check out the vibrant tech community on one of the world's most
engaging tech sites,
30.12.2016 15:59, Alex Peshkoff wrote:
> Definitely not limited. But it's good idea to discuss new feature before
> implementing it (specially if it's not already in the tracker).
Ok. Do anybody object if I try to dig a little into CORE-5064?
--
WBR, SD.
-
30.12.2016 15:52, Kovalenko Dmitry wrote:
> No. It need for resolve a problem with cancelation of operations.
>
> http://tracker.firebirdsql.org/browse/CORE-5152
I'm sorry, but could you explain a little: how packet length can help in
this case?
> It will allow with minimal efforts detect the
On 12/30/16 17:54, Dimitry Sibiryakov wrote:
> Hello, All.
>
> Is list of features for version 4 limited to listed in roadmap?
> I.e. if I pull request for something else will it be rejected for sure?
Definitely not limited. But it's good idea to discuss new feature before
implementin
Hello, All.
Is list of features for version 4 limited to listed in roadmap?
I.e. if I pull request for something else will it be rejected for sure?
--
WBR, SD.
--
Check out the vibrant tech community on one
>4) Knowledge of total length of packet is required only for current parser
which need full packet to be in single buffer. If rewrite parser to use
stateful automate, total length is needless.
No. It need for resolve a problem with cancelation of operations.
http://tracker.firebirdsql.org/browse/
30.12.2016 12:19, Dimitry Sibiryakov wrote:
> 1) Core team have no time for it.
> 2) Core team have no time to review big patches from outsiders.
> 3) Backward compatibility has to be kept.
4) Knowledge of total length of packet is required only for current parser
which need full
packet to be in
30.12.2016 14:19, Dimitry Sibiryakov wrote:
>
> 1) Core team have no time for it.
True.
> 2) Core team have no time to review big patches from outsiders.
Bullshit.
> 3) Backward compatibility has to be kept.
True. What a surprise!
Dmitry
---
30.12.2016 12:10, Kovalenko Dmitry wrote:
>>From my point of view, protocol must be rewrited
>
> At minimum:
> 1. The each packet should contain the field with own size.
> 2. It is necessary to solve the problems with LazySend mode.
1) Core team have no time for it.
2) Core team have no time to re
>From my point of view, protocol must be rewrited
At minimum:
1. The each packet should contain the field with own size.
2. It is necessary to solve the problems with LazySend mode.
Dmity Kovalenko
www.ibprovider.com
-Original Message-
From: Mark Rotteveel [mailto:m...@lawinegevaar.nl]
Fixed
Regards,
Vlad
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at
https://lists.sourcefor
12 matches
Mail list logo