I think Kevin was asking whether or not strings are null terminated.
I know nothing about the GT.M source, but as a general sort answer:
Databases don't typically store data in a "packed" format (like the
run-time heap), but instead storage is allocated in fixed size
chunks, which are then typically organized into a structure called a
B-tree. This makes it possible to add and delete records (nodes) or
to modify the size of an existing node without having to drastically
modify the entire structure. (So far as I know, the origin of the
term B-tree is unknown, but I like to think of them as "bushy" trees.)
===
Gregory Woodhouse
[EMAIL PROTECTED]
"Design quality doesn't ensure success, but design failure can ensure
failure."
--Kent Beck
On Aug 23, 2005, at 2:54 PM, K.S. Bhaskar wrote:
Probably not of much value to ask unless you are a GT.M internals
developer - details are in the source code. As a gross simplification
(along the lines of saying that living things are made up of cells),
GT.M stores the length and actual value of each string. But there are
all sorts of optimizations, including key compression when stored
in the
database.
-- Bhaskar
On Tue, 2005-08-23 at 16:22 -0500, Kevin Toppenberg wrote:
So Bhaskar, is of any value to ask how the data is stored behind the
scenes? I was worried that the strings were null-terminated etc and
that there might be some binary data that would crash GT.M. when
storing is in a global value.
I'm glad to hear that is not the case.
Kevin
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
