Monty Taylor wrote:
Antony T Curtis wrote:
I have never felt the need to dig into its implementation issues... I
kinda simply assumed that when it went in, that there must have been
some real good reason why one of the existing GPL or BSD big number
libraries wasn't selected.
The sadness. The sadness.
Personally, I didn't like it because it added more methods to the
already overloaded and overcomplicated Item classes. Every time I see an
"if" or "switch" statement with a const argument, my mind wonders why
wasn't object orientation used instead...
Totally, 100% agree.
The solution to virtually all datatype problems is to use value
objects. A value object can be treated as an abstract value that
encapsulates actual types. A value object can be set to any type and
any type can be fetched from it. If the type set and requested are the
same, the primitive values are identical. If different, the value
object performs a conversion or throws an error.
With value objects, 99% of the code can operate without any knowledge of
specific types. Among many other benefits, this means new types can be
added without chasing down the 250 places that now know about types.
The best way to structure the server is to have the storage engines
return abstract Record objects with methods to set a value object with
the value of a field (id) or use the value of a value object to set the
value of a field. This has all sorts of goodnesses:
1. It eliminates the concept of canonical server record, eliminating
the expensive mapping between engine and server record formats.
2. It allows deferred blob materialization.
3. It makes phasing in new datatypes easy. For example,
drizzle/MySQL is sorely lacking a decimal scaled binary type,
which is about a million times faster than the idiotic "decimal"
computational type now in use.
4. It encapsulates all conversion code in one spot, eliminate hordes
of "almost" compatible conversions sprinkled around the code.
5. It provides a trivial and consistent mechanism for passing values
around the server.
6. It encapsulates management of string copies (when necessary),
reducing code and potential memory leaks.
7. It would get raw data pointers out of the field tree allowing the
field tree to be shared among threads.
If anyone wants an example of a value object, see Value.h and Value.cpp
in Falcon.
The downside, of course, is that value objects are objects, requiring
mastery of the concept of encapsulation and abstraction. That's a
pretty big step for database guys.
--
Jim Starkey
President, NimbusDB, Inc.
978 526-1376
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
