* Øystein Grøvlen <Oystein.Grovlen@stripped> [09/05/22 14:10]:
> I am working on extracting much duplicated type conversion code from
> Item classes and Field classes into a Value class. (See
> http://forge.mysql.com/worklog/task.php?id=4760). Note that the
> architectural review for this worklog is still pending, but a
> preliminary patch for the Field classes part can be found at
> Comments are very welcomed.
Field types and Item types are two different type systems.
Field type system is strongly typed. An attempt to store an
integer in a string type should produce a warning or error.
Type arithmetics is not supported: i.e. the server never adds
INT(5) to INT(5), first it converts the field to an Item type system INT
(which is 64 bit weakly typed) and then adds these two.
Item type system is weakly typed. There are only 4 basic types
(which you have implemented). Arithmetic operations are supported.
Now, the protocol storage format is in Field type system.
When protocol requests a Field_short to store itself in the binary
format, it expects the result to be two byte in little-endian
Thus delegating storage of Field value to your current
implementation of Value object, which only
knows about 4 weak types of Item arithmetics, can't lead to a
correct result, since the operation is not defined for it.
The initial idea for the value object was an interface of the PSEA
API, that could by the storage engine to ship data up to the
server and back, rather than use the MyISAM record format.
That would avoid unnecessary copying and conversion of data on
You started from Item level, which is fine, but you should realize
that the key property of Value object is a common interface, that
could be implemented by both engine and SQL.
During Value object debates which I was part of, nobody asked a
question how to correctly implement morphing of an object which
comes from the storage engine and is strongly typed to an object
in the Item arithmetics universe, and back. I'd be glad to know
what solution you came to at the re-engineering discussions, since
now your implementation approached a place where it is needed.
On a practical note, I suggest you do nothing about the case today
and concentrate on the implementation that transfers the ownership
of data from Item to Value.
> I am currently looking at the interaction between Field and Protocol,
> and would appreciate some input.
> Each Field subclass has a send_binary() method (a bit misleading name
> since it depends on the protocol whether what it sends is binary or
> textual.) Currently, these methods calls a corresponding
> Protocol::store_xxx() method, and in my preliminary patch this looks
> something like this:
> bool Field_short::send_binary(Protocol *protocol)
> return protocol->store_short(value().get_int());
> I think it would be a good idea to add a Protocol::store(Value) method
> that will be called from Field::send_binary(Protocol*). Then all the
> overriding send_binary methods in the Field subclasses could be dropped.
> Protocol_text::store(Value) could just call Value::to_string() to get
> the textual representation of the Value. The question is what to do for
> Protocol_binary and other protocols.
> One option for Protocol_binary would be to introduce a
> Value::to_binary() method. However, I feel that the Value object may
> take on too much responsibility if it is to know about value
> representation in different protocols and have a to_xxx() method for
> An alternative is to add a Value::type() method and let each protocol do
> its own conversion based on the type. This creates another dependency
> since the type representation used by Value will have to be exposed.
> Both alternatives means that Value needs to know the exact SQL type of a
> Value. For the current patch, it is sufficient for Value to know it is
> an integer, whether it is a 1-byte integer or a 4-byte is not relevant
> for conversion to real, string, or decimal.
> Øystein Grøvlen, Senior Staff Engineer
> Sun Microsystems, Database Group
> Trondheim, Norway
> MySQL Internals Mailing List
> For list archives: http://lists.mysql.com/internals
> To unsubscribe: http://lists.mysql.com/internals?unsub=1