Thank you for posting this. I agree with you 100%. I'd like to add
that in the context of the current MySQL internal architecture, Value
objects make very little sense to me. I am not sure I understand the
intended purpose and benefit of this development task and of Value
2009/5/22 Konstantin Osipov <kostja@stripped>:
> * Ø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
> engine level.
> 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
> MySQL Internals Mailing List
> For list archives: http://lists.mysql.com/internals
> To unsubscribe: http://lists.mysql.com/internals?unsub=1