On 5-9-2013 16:45, Jim Starkey wrote:
The keys to reducing round trips are to bundle metadata with data to
eliminate the need for info trips and, most importantly, to batch
record retrievals and batch inserts into single large packets. Sending a
MB worth of records is obviously a great win.
On 09/04/13 18:11, Jim Starkey wrote:
So here's another seriously heretical thought. If you're planning for
Firebird to hang around another 27 years, it's time to define a modern
OO API that is easy to use from modern languages, is flexible and
extensible, supports an efficient remote
On 9/5/2013 4:28 AM, Alex Peshkoff wrote:
On 09/04/13 18:11, Jim Starkey wrote:
So here's another seriously heretical thought. If you're planning for
Firebird to hang around another 27 years, it's time to define a modern
OO API that is easy to use from modern languages, is flexible and
On 05/09/13 15:45, Jim Starkey wrote:
While I was pointing out that the worst part of
starting a new software company was rewriting stringToDate, a
completely new, incredibly efficient, open ended algorithm for that
class of conversions occurred to me. It's really cute, and if anyone is
04.09.2013 11:43, Alex Peshkoff wrote:
May be in that case next step? Keep declaring strings as char(N), but
treat N not as maximum size of string
Please don't play against the SQL standard. The declared string length
is a constraint which must be enforced.
Dmitry
On 09/04/13 11:53, Dmitry Yemanov wrote:
04.09.2013 11:43, Alex Peshkoff wrote:
May be in that case next step? Keep declaring strings as char(N), but
treat N not as maximum size of string
Please don't play against the SQL standard. The declared string length
is a constraint which must be
On 09/04/13 11:53, Dmitry Yemanov wrote:
04.09.2013 11:43, Alex Peshkoff wrote:
May be in that case next step? Keep declaring strings as char(N), but
treat N not as maximum size of string
Please don't play against the SQL standard. The declared string length
is a constraint which must be
On 04/09/2013 05:09, Alex Peshkoff wrote:
On 09/04/13 11:53, Dmitry Yemanov wrote:
04.09.2013 11:43, Alex Peshkoff wrote:
May be in that case next step? Keep declaring strings as char(N), but
treat N not as maximum size of string
Please don't play against the SQL standard. The declared string
04.09.2013 12:40, Adriano dos Santos Fernandes wrote:
The name of this type, a long and unlimited string, is CLOB.
But what value will be in XSQLVAR.sqltype?
--
WBR, SD.
--
Learn the latest--Visual Studio 2012,
On 09/04/13 14:46, Dimitry Sibiryakov wrote:
04.09.2013 12:40, Adriano dos Santos Fernandes wrote:
The name of this type, a long and unlimited string, is CLOB.
But what value will be in XSQLVAR.sqltype?
Not sure it will be supported in SQLDA API...
04.09.2013 12:56, Alex Peshkoff wrote:
Not sure it will be supported in SQLDA API...
Why not? There are at least two ways: client-side blob id and
clent-assigned sqldata.
--
WBR, SD.
--
Learn the latest--Visual
On 09/04/13 14:59, Dimitry Sibiryakov wrote:
04.09.2013 12:56, Alex Peshkoff wrote:
Not sure it will be supported in SQLDA API...
Why not?
That all is about the future version of firebird, let's call it FB4.
Certainly (hmm, at least on my mind) we will continue supporting
backward
Unbounded types work very badly with the SQLDA. The original SQLDA was
lifted verbatim from the DB2 spec, circa 1985, because I wanted
something more or less standard. It was pretty much awful then and it
hasn't gotten much prettier since. On the other hand, it's what
everything uses for
On 04/09/2013 11:00, Jim Starkey wrote:
a blob that is thought to be character
And a string with unlimited length is nothing than a blob that is
thought to be character.
If you implement it efficiently or not, is another matter.
Adriano
A clob is nothing but a blob that is thought to be character.
On 9/4/2013 6:40 AM, Adriano dos Santos Fernandes wrote:
On 04/09/2013 05:09, Alex Peshkoff wrote:
On 09/04/13 11:53, Dmitry Yemanov wrote:
04.09.2013 11:43, Alex Peshkoff wrote:
May be in that case next step? Keep declaring
Den 2013-09-02 16:53 skrev Jim Starkey såhär:
Let me offer another humble suggestion, though one that should not be
a candidate for FB3: Ditch the concept of fixed length records,
completely and forever.
I really really really like this!
Kjell
--
--
On 09/03/13 11:02, Kjell Rilbe wrote:
Den 2013-09-02 16:53 skrev Jim Starkey såhär:
Let me offer another humble suggestion, though one that should not be
a candidate for FB3: Ditch the concept of fixed length records,
completely and forever.
I really really really like this!
That's
03.09.2013 9:13, Alex Peshkoff wrote:
But I see one problem -
currently all (or at least most of all) record buffers are allocated at
prepare time. With variable record length this strategy requires change,
and that change does not look trivial at the first glance.
What problem do you
03.09.2013 11:13, Alex Peshkoff wrote:
That's definitely a candidate for next ODS. But I see one problem -
currently all (or at least most of all) record buffers are allocated at
prepare time. With variable record length this strategy requires change,
and that change does not look trivial at
On 09/03/13 13:04, Dimitry Sibiryakov wrote:
03.09.2013 9:13, Alex Peshkoff wrote:
But I see one problem -
currently all (or at least most of all) record buffers are allocated at
prepare time. With variable record length this strategy requires change,
and that change does not look trivial at
03.09.2013 11:22, Alex Peshkoff wrote:
Add dynamic allocation to SQZ?
No.
SQZ pack RecordBuffer into fixed-size pages, there is no need for dynamic
allocation there.
Dynamic allocation is needed in RecordBuffer only and only for strings.
--
WBR, SD.
On 09/03/13 13:21, Dmitry Yemanov wrote:
03.09.2013 11:13, Alex Peshkoff wrote:
That's definitely a candidate for next ODS. But I see one problem -
currently all (or at least most of all) record buffers are allocated at
prepare time. With variable record length this strategy requires change,
On Tue, Sep 3, 2013 at 5:04 AM, Dimitry Sibiryakov s...@ibphoenix.com wrote:
What problem do you foresee?
AFAIK, ccess to single field values is already incapsulated in record
class, so string
buffer in DSC can be replaced with pointer without hacking whole engine.
So, only SQZ
On 9/3/2013 8:02 AM, Alex Peshkoff wrote:
On 09/03/13 13:21, Dmitry Yemanov wrote:
03.09.2013 11:13, Alex Peshkoff wrote:
That's definitely a candidate for next ODS. But I see one problem -
currently all (or at least most of all) record buffers are allocated at
prepare time. With variable
Let me offer another humble suggestion, though one that should not be a
candidate for FB3: Ditch the concept of fixed length records,
completely and forever.
Let me sketch the scheme I used in Netfrastructure / Falcon, which
originated from a suggestion on this list. The key elements are:
25 matches
Mail list logo
