On 03/12/14 19:35, Dimitry Sibiryakov wrote:
> 12.03.2014 16:06, Dmitry Yemanov wrote:
>> 12.03.2014 18:56, Dimitry Sibiryakov wrote:
>>
>>> But at first I need to find out why it is crashing. Wide result sets
>>> are allowed, but
>>> is wide input data supposed to work as well? Must following SQL
12.03.2014 16:06, Dmitry Yemanov wrote:
12.03.2014 18:56, Dimitry Sibiryakov wrote:
But at first I need to find out why it is crashing. Wide result sets are
allowed, but
is wide input data supposed to work as well? Must following SQL to be executed
ok:
select cast(? as varchar(32000)) a,cast
12.03.2014 16:06, Dmitry Yemanov wrote:
> Do you have a stack trace for the crash?
No. Strange visual studio somehow refuse to debug. I can provide test app if
you wish.
--
WBR, SD.
--
Learn Graph Databases - Dow
12.03.2014 18:56, Dimitry Sibiryakov wrote:
> But at first I need to find out why it is crashing. Wide result sets are
> allowed, but
> is wide input data supposed to work as well? Must following SQL to be
> executed ok:
>
> select cast(? as varchar(32000)) a,cast(? as varchar(32000)) b,cast(? a
12.03.2014 15:26, Alex Peshkoff wrote:
> That's not a matter of only SQLDA->metadata transformation. It's working
> with transactions from SQL, named cursors, may be something else.
This is just a couple of lines, I see no point to create separate routine
for such
little things.
> Send
> me
On 03/12/14 18:19, Dimitry Sibiryakov wrote:
> 12.03.2014 15:13, Alex Peshkoff wrote:
>> On 03/12/14 18:07, Dimitry Sibiryakov wrote:
>>> Could you explain the purpose of these *_32bits_m() functions,
>>> please?..
>> They contain common code which was duplicated in your patch.
> I said
12.03.2014 15:13, Alex Peshkoff wrote:
> On 03/12/14 18:07, Dimitry Sibiryakov wrote:
>> Could you explain the purpose of these *_32bits_m() functions, please?..
>
> They contain common code which was duplicated in your patch.
I said that I was going to prepare second version of the patch,
On 03/12/14 18:07, Dimitry Sibiryakov wrote:
>> I've applied it to one of tree copies last week and always updated from
>> svn w/o problems.
> Could you explain the purpose of these *_32bits_m() functions, please?..
They contain common code which was duplicated in your patch.
-
12.03.2014 14:48, Alex Peshkoff wrote:
> For different versions we need to take into an account differetnt
> offsets in that array. Possible, but very unsane.
Fortunately, all offsets in this case are known at compile time, no runtime
calculations.
> I've applied it to one of tree copies last
On 03/12/14 17:24, Dimitry Sibiryakov wrote:
> 12.03.2014 14:01, Alex Peshkoff wrote:
>> It's easy to add new fields to XSQLDA, but adding something to XSQLVAR
>> is much harder because there is an array of this structures in the end
>> of XSQLDA. From user POV this looks fine, but inside firebird
12.03.2014 14:01, Alex Peshkoff wrote:
> It's easy to add new fields to XSQLDA, but adding something to XSQLVAR
> is much harder because there is an array of this structures in the end
> of XSQLDA. From user POV this looks fine, but inside firebird library we
> get nightmare.
No, not at all. Or
On 03/12/14 16:48, Dimitry Sibiryakov wrote:
> 12.03.2014 13:24, Alex Peshkoff wrote:
>> On 03/12/14 15:41, Dimitry Sibiryakov wrote:
>>> SQLDA is expandable. That's what field version is for.
>> Formally - yes, actually - no. Expanding it is nightmare. Or may be you
>> really think that char
12.03.2014 13:24, Alex Peshkoff wrote:
> On 03/12/14 15:41, Dimitry Sibiryakov wrote:
>> SQLDA is expandable. That's what field version is for.
>
> Formally - yes, actually - no. Expanding it is nightmare. Or may be you
> really think that charset code returned in some fine fields like subtype
On 03/12/14 15:41, Dimitry Sibiryakov wrote:
> 12.03.2014 11:33, Alex Peshkoff wrote:
>> But if someone wants to built one more level of API_over_ plain
>> messages (like it was with SQLDA, but please expandable!) I see no
>> problems with it.
> SQLDA is expandable. That's what field version i
12.03.2014 11:33, Alex Peshkoff wrote:
> But if someone wants to built one more level of API_over_ plain
> messages (like it was with SQLDA, but please expandable!) I see no
> problems with it.
SQLDA is expandable. That's what field version is for.
> Moreover, high
> performance requirements
On 03/11/14 21:26, Dimitry Sibiryakov wrote:
> I prefer Newton and Einstein to be wrong about gravitation because flying
> is more
> convenient than walking. But we have to live with reality. ;)
If we return to reality we will see that firebird/interbase API always
used to work with message
11.03.2014 15:45, Adriano dos Santos Fernandes wrote:
> If you want compile-time fixed queries and data structures, use FB_MESSAGE.
>
> Dynamically, SQLDA is also the same mess.
IMHO, it is much lesser mess than four levels of macros from boost.
--
WBR, SD.
---
11.03.2014 17:09, Alex Peshkoff wrote:
> On 03/11/14 19:54, Dimitry Sibiryakov wrote:
>> Unfortunately, at the same time it makes any other using as hard as
>> possible.
>> Flexibility is lacked.
>
> Did you pay attention to what Adriano suggested? Wrappers on the top of
> the API.
Yes, b
On 03/11/14 19:54, Dimitry Sibiryakov wrote:
> 11.03.2014 15:21, Alex Peshkoff wrote:
>> On 03/11/14 17:39, Dimitry Sibiryakov wrote:
>>> IMHO, right way is to hide field order behind interface.
>> Sorry, but field _order_ should better match order of output fields in
>> select for output mes
11.03.2014 15:21, Alex Peshkoff wrote:
> On 03/11/14 17:39, Dimitry Sibiryakov wrote:
>> IMHO, right way is to hide field order behind interface.
>
> Sorry, but field _order_ should better match order of output fields in
> select for output messages and order of '?' parameters in input
> messa
On 11/03/2014 11:58, Dimitry Sibiryakov wrote:
> 11.03.2014 15:45, Alex Peshkoff wrote:
>> I know very well it's not optimal, but currently have no time for
>> optimization.
>It is not isql that requires optimization. Anything you can do in it will
> be either
> routines for getting pointer f
11.03.2014 15:45, Alex Peshkoff wrote:
> I know very well it's not optimal, but currently have no time for
> optimization.
It is not isql that requires optimization. Anything you can do in it will be
either
routines for getting pointer from index (what I suggested for IBuffer) or
emulation o
On 03/11/14 18:38, Dimitry Sibiryakov wrote:
> 11.03.2014 15:23, Alex Peshkoff wrote:
>> Just as a sample - even bad non-optimal isql prints data directly from
>> message buffer, not copying them.
> Yes. And code that do that is a masive copy-past of crap like this:
>
> > var->nullInd = (sho
On 11/03/2014 11:38, Dimitry Sibiryakov wrote:
> 11.03.2014 15:23, Alex Peshkoff wrote:
>> Just as a sample - even bad non-optimal isql prints data directly from
>> message buffer, not copying them.
>Yes. And code that do that is a masive copy-past of crap like this:
>
> > var->nullInd = (sho
11.03.2014 15:23, Alex Peshkoff wrote:
> Just as a sample - even bad non-optimal isql prints data directly from
> message buffer, not copying them.
Yes. And code that do that is a masive copy-past of crap like this:
> var->nullInd = (short*) &buf[msg->getNullOffset(fbStatus, index)];
> if
On 03/11/14 17:39, Dimitry Sibiryakov wrote:
>> What may be discussed is should we document exact order of fields in the
>> message or probably let user create arbitrary one. If we decide to use 2
>> approach - them offsets really should travel over the wire.
> No, please. Read again: document
11.03.2014 15:09, Adriano dos Santos Fernandes wrote:
> The idea is that if you "select a, b, c", you will need "a", "b" and
> "c", so makes sense to store them together.
>
> If you want to have them in each place of memory, you may copy them.
The contrary is also true: if you "insert values (:
On 03/11/14 18:09, Adriano dos Santos Fernandes wrote:
> On 11/03/2014 10:51, Dimitry Sibiryakov wrote:
>> 11.03.2014 14:04, Adriano dos Santos Fernandes wrote:
>>> A possible solution may be to separate offset calculation from
>>> IMessageMetadata.
>> Quoting one movie, "offsets are not import
On 11/03/2014 10:51, Dimitry Sibiryakov wrote:
> 11.03.2014 14:04, Adriano dos Santos Fernandes wrote:
>> A possible solution may be to separate offset calculation from
>> IMessageMetadata.
>Quoting one movie, "offsets are not important, only data is important".
> Leave offsets
> to engine, i
11.03.2014 14:04, Adriano dos Santos Fernandes wrote:
> A possible solution may be to separate offset calculation from
> IMessageMetadata.
Quoting one movie, "offsets are not important, only data is important".
Leave offsets
to engine, if it cannot work other way, but save users from them.
11.03.2014 13:48, Alex Peshkoff wrote:
> On 03/11/14 15:58, Dimitry Sibiryakov wrote:
>> Fix every user application using API to create data buffers in exact
>> format? It is not
>> good because a) won't let change this format ever and b) too cruel.
>
> I understand your worries. Will try to
On 03/11/14 17:32, Adriano dos Santos Fernandes wrote:
> On 11/03/2014 10:22, Alex Peshkoff wrote:
>> On 03/11/14 17:04, Adriano dos Santos Fernandes wrote:
>>
>>> A possible solution may be to separate offset calculation from
>>> IMessageMetadata.
>>>
>>> Something like:
>>>
>>> IMessageMetadata*
On 11/03/2014 10:22, Alex Peshkoff wrote:
> On 03/11/14 17:04, Adriano dos Santos Fernandes wrote:
>
>> A possible solution may be to separate offset calculation from
>> IMessageMetadata.
>>
>> Something like:
>>
>> IMessageMetadata* mm = ...
>>
>> unsigned offsets[5], nullOffsets[5];
>>
>> IUtil*
On 03/11/14 17:04, Adriano dos Santos Fernandes wrote:
> A possible solution may be to separate offset calculation from
> IMessageMetadata.
>
> Something like:
>
> IMessageMetadata* mm = ...
>
> unsigned offsets[5], nullOffsets[5];
>
> IUtil* util = dispatcher->getUtil();
> util->getOffsets(mm, of
Without look at the details of everything, I think I understand (and may
agree) with what Dimitry is saying.
getOffset / getNullOffset are very util to get offsets described by the
engine.
But when the user is passing them to the engine, it's a duplicated
information that should be in sync with t
On 03/11/14 15:58, Dimitry Sibiryakov wrote:
>>> As the example: common/calsses/InternalMessageBuffer produces message
>>> metadata from BLR
>>> using MetadataFromBlr(). After that remote/client/BlrFromMessage produces
>>> _different_ BLR
>>> from input message metadata, but the rest of in
11.03.2014 11:56, Alex Peshkoff wrote:
> whole libc is one big "architectural mistake". But usually it's called
> implementation detail :)
It is rather missing fool-proof.
>> As the example: common/calsses/InternalMessageBuffer produces message
>> metadata from BLR
>> using MetadataFromB
Sorry for late answer - missed this letter on holidays
On 03/07/14 17:51, Dimitry Sibiryakov wrote:
> 07.03.2014 14:15, Alex Peshkoff wrote:
>> n 03/07/14 16:45, Dimitry Sibiryakov wrote:
After prepare we get from server a metadata-only object. There is no
need in offsets in
t
07.03.2014 14:15, Alex Peshkoff wrote:
> n 03/07/14 16:45, Dimitry Sibiryakov wrote:
>> > After prepare we get from server a metadata-only object. There is no
>> > need in offsets in
>> >this object. Offsets are not a part of metadata at all, IMHO, and their
>> >presence in
>> >IMessageMetada
On 03/07/14 16:45, Dimitry Sibiryakov wrote:
> 07.03.2014 13:18, Alex Peshkoff wrote:
>> On 03/07/14 15:14, Dimitry Sibiryakov wrote:
>>> There is no difference if you store offset got from a virtual
>>> function or a pointer got
>>> from other virtual function. In any case you'll have to pe
07.03.2014 13:18, Alex Peshkoff wrote:
> On 03/07/14 15:14, Dimitry Sibiryakov wrote:
>> There is no difference if you store offset got from a virtual function
>> or a pointer got
>> from other virtual function. In any case you'll have to perform
>> "buffer+offset" operation
>> every time yo
On 03/07/14 15:14, Dimitry Sibiryakov wrote:
> 07.03.2014 11:53, Alex Peshkoff wrote:
>
>> Main reason is performance compromise. It's faster to store required
>> information from IMessageMetadata somewhere in end-user code and use it
>> to access data instead of calling dozens of virtual functions
07.03.2014 11:53, Alex Peshkoff wrote:
> Main reason is performance compromise. It's faster to store required
> information from IMessageMetadata somewhere in end-user code and use it
> to access data instead of calling dozens of virtual functions.
There is no difference if you store offset go
On 03/07/14 13:54, Dimitry Sibiryakov wrote:
> 07.03.2014 10:44, Alex Peshkoff wrote:
>> Yes. That's one of the reasons. Among others is the fact that
>> IMessageMetadata may be returned from server after prepare, and at this
>> step we have no buffer: it will be allocated after receiving metainfo
07.03.2014 10:44, Alex Peshkoff wrote:
> Yes. That's one of the reasons. Among others is the fact that
> IMessageMetadata may be returned from server after prepare, and at this
> step we have no buffer: it will be allocated after receiving metainfo
> based upon size of message from that info.
I
On 03/07/14 12:50, Dimitry Sibiryakov wrote:
> Do I understand right that these things are splitted to be able to have
> many message
> (record data) buffers at once under control of one metadata object? Because
> of that
> IMessageMetadata operate by offsets instead of pointers?
>
Yes. That
46 matches
Mail list logo
