Konstantin Osipov wrote:
> * Ø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.
So far my Value object knows nothing about arithmetics, all they know
about is how to convert between types. However, it needs to distinguish
between more than just four types. For example, conversion between
integer and string will be different for a Field_timestamp than for a
> 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.
AFAIU, this is not within the scope of the task I have been given and
how it is reflected in the worklog description. However, the worklog
has not yet been approved so it remains to see if I have misunderstood.
> 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.
This has not be discussed much yet. However, it is something I will
look into as I start working on the Item hierarchy. So far, my focus
have been on the Field classes.
> 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.
The way I have understood it from discussions in the re-engineering
team, I am not going to transfer ownership of data from Item to Value.
So far, Value objects are just used for return values that can easily
converted to other types.