>I needed comments from developers also
Then post links to working sites ;) I can't access it whole yesterday
and today nothing changed.
Regards,
Vlad
--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Da
On Tuesday 11 March 2014 08:27:20 Vlad Khorsun wrote:
> >I needed comments from developers also
>
> Then post links to working sites ;) I can't access it whole yesterday
> and today nothing changed.
>
It worked first thing in the morning when I checked it yesterday. Obviously
the massive inte
>It worked first thing in the morning when I checked it yesterday. Obviously
>the massive >interest from firebird devs has overwhelmed the site.
Also worked for me too yesterday. Must've been a popular article ;-)
--
11.03.2014 11:27, Vlad Khorsun wrote:
> Then post links to working sites ;) I can't access it whole yesterday
> and today nothing changed.
Same here, although I managed to access that article via a different URL
yesterday:
http://www.tuicool.com/articles/qIvAra
It also works badly, but the Goog
11.03.2014 09:59, marius adrian popa wrote:
> I needed comments from developers also
You'd better ask questions then. I don't care to comment what unknown
people write about Firebird over the internet.
Dmitry
--
Lear
you can check the google cache
write in google:
cache:http://ocelot.ca/blog/blog/2014/03/09/354/
or coral cache
http://ocelot.ca.nyud.net/blog/blog/2014/03/09/354/
but some comments / content can be stalled
On Tue, Mar 11, 2014 at 9:27 AM, Vlad Khorsun
wrote:
>>I needed comments from developer
marius adrian popa wrote:
> I needed comments from developers also
And developers don't read firebird-general?
What is more irritating is seeing the same stuff over and over again!
--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Ele
On 03/11/2014 12:22 PM, Dmitry Yemanov wrote:
> 11.03.2014 09:59, marius adrian popa wrote:
>
>> I needed comments from developers also
> You'd better ask questions then. I don't care to comment what unknown
> people write about Firebird over the internet.
+1
-
Marius,
> you can check the google cache
Why should i spend my time to investigate (!) how to access it ???
Does it have something important for Firebird ? Something new ?
Or what ?
Regards,
Vlad
--
Learn Grap
> On 03/11/2014 12:22 PM, Dmitry Yemanov wrote:
>> 11.03.2014 09:59, marius adrian popa wrote:
>>
>>> I needed comments from developers also
>> You'd better ask questions then. I don't care to comment what unknown
>> people write about Firebird over the internet.
> +1
++
Vlad
---
> > you can check the google cache
>
> Why should i spend my time to investigate (!) how to access it ???
>
> Does it have something important for Firebird ? Something new ?
> Or what ?
Allow me behead him.
Dmitry Kovalenko.
---
11.03.2014 8:41, Maya Opperman wrote:
>> It worked first thing in the morning when I checked it yesterday. Obviously
>> the massive >interest from firebird devs has overwhelmed the site.
>
> Also worked for me too yesterday. Must've been a popular article ;-)
This site just blocks users from R
11.03.2014 6:38, Alex wrote:
> On 03/09/2014 03:43 PM, Dimitry Sibiryakov wrote:
>> What's the purpose for IMessageMetadata::getLength() method to be
>> declared as const?
>> Such declaration makes impossible to calculate length on demand and cache
>> the result for
>> future calls. Implemen
Marius,
All I would observe is that you cannot usefully compare two RDBMSs
without considering how well they support the applications that use
them. Indeed you have to look at the whole lifecycle from design,
development and test through to field support and deployment to get a
real feel about how
On Tue, 11 Mar 2014 12:59:32 +0400, Dmitry Kovalenko
wrote:
>> > you can check the google cache
>>
>> Why should i spend my time to investigate (!) how to access it ???
>>
>> Does it have something important for Firebird ? Something new ?
>> Or what ?
>
>
> Allow me behead him.
Could we ple
On 03/11/14 13:14, Dimitry Sibiryakov wrote:
> 11.03.2014 6:38, Alex wrote:
>> On 03/09/2014 03:43 PM, Dimitry Sibiryakov wrote:
>>> What's the purpose for IMessageMetadata::getLength() method to be
>>> declared as const?
>>> Such declaration makes impossible to calculate length on demand an
11.03.2014 11:40, Alex Peshkoff wrote:
> in this case getLength() declaration should better be corrected.
> We nowhere use const interfaces.
The rest of methods also should be changed then. It is better to do now than
workaround
their inability to call non-const methods later.
--
WBR, SD
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
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
On 03/11/14 14:50, Dimitry Sibiryakov wrote:
> 11.03.2014 11:40, Alex Peshkoff wrote:
>> in this case getLength() declaration should better be corrected.
>> We nowhere use const interfaces.
> The rest of methods also should be changed then. It is better to do now
> than workaround
> their inab
I cannot open it too
Regards,
Alexey
> On 03/10/2014 11:00 AM, marius adrian popa wrote:
>> I decided to compare the current versions of MySQL 5.6 and Firebird
>> SQL 2.5. I only looked at features that end users can see, without
>> benchmarking. http://ocelot.ca/blog/blog/2014/03/09/354/
> Is it
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
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 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
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: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*
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
I posted here so maybe it can help us to update the sql conformance
page http://www.firebirdsql.org/en/sql-conformance/
Sorry for cross posting so much , maybe i was over to much coffeine
also i didn't had the time to explain what is with the link
ps: he is not quite a random guy on the internet
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.
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
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
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 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: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
random results in logical operations on rand() generated numbers
Key: CORE-4362
URL: http://tracker.firebirdsql.org/browse/CORE-4362
Project: Firebird Core
Issue Type: Bug
>I posted here so maybe it can help us to update the sql conformance
> page http://www.firebirdsql.org/en/sql-conformance/
>
> Sorry for cross posting so much , maybe i was over to much coffeine
> also i didn't had the time to explain what is with the link
>
> ps: he is not quite a random guy on
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
>
> b) T021 BINARY and VARBINARY data types
> Firebird doesn't have this.
>
> Firebird have [VAR]CHAR CHARACTER SET OCTETS data type which is exactly
> the same as [VAR]BINARY, AFAIU.
BTW, this is a case where adding std-compliant syntax appears possible
and simple.
--
Ann and I know Peter and his wife Trudy very well. For most of the time
we were there, Trudy was the other woman in engineering. Peter is much
more of a theoretician than a developer, so he may not be fully up to
speed on the practical implications of some of this stuff.
The MySQL engineering
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
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 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: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 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 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
> -Original Message-
> From: Dmitry Kovalenko [mailto:dmitry.lipe...@gmail.com]
> Sent: Martes, 11 de Marzo de 2014 5:00
>
> Allow me behead him.
>
> Dmitry Kovalenko.
You can beat him with a whip made of barbed wire if you want, but you don't
have permission to kill him. Marius is a ti
Marius, you posted at least to three lists. More than enough. Same as
Lester, I find obnoxious to see the same matter scattered over several
forums.
C.
> -Original Message-
> From: marius adrian popa [mailto:map...@gmail.com]
> Sent: Martes, 11 de Marzo de 2014 2:00
>
> I needed comment
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.
---
> -Original Message-
> From: Dimitry Sibiryakov [mailto:s...@ibphoenix.com]
> Sent: Martes, 11 de Marzo de 2014 5:15
>
> 11.03.2014 6:38, Alex wrote:
> > On 03/09/2014 03:43 PM, Dimitry Sibiryakov wrote:
> >
> > For me it looks like historical artifact from some old
> > implementation.
>
On Tue, Mar 11, 2014 at 9:47 AM, marius adrian popa wrote:
> I posted here so maybe it can help us to update the sql conformance
> page http://www.firebirdsql.org/en/sql-conformance/
>
> ps: he is not quite a random guy on the internet but a quite biased at the
> end
> Software Architect at MySQL
On 03/12/14 00:14, Claudio Valderrama C. wrote:
>> -Original Message-
>> From: Dimitry Sibiryakov [mailto:s...@ibphoenix.com]
>> Sent: Martes, 11 de Marzo de 2014 5:15
>>
>> 11.03.2014 6:38, Alex wrote:
>>> On 03/09/2014 03:43 PM, Dimitry Sibiryakov wrote:
>>>
>>> For me it looks like histo
51 matches
Mail list logo
