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.
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)
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 each.
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