List:Internals« Previous MessageNext Message »
From:Øystein Grøvlen Date:May 22 2009 10:00am
Subject:Value objects and Protocol (WL#4760)
View as plain text  
Hi,

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 
http://lists.mysql.com/commits/74564.
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)
{
   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 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.

Opinions?

--
Øystein Grøvlen, Senior Staff Engineer
Sun Microsystems, Database Group
Trondheim, Norway





Thread
Value objects and Protocol (WL#4760)Øystein Grøvlen22 May
  • Re: Value objects and Protocol (WL#4760)Konstantin Osipov22 May
    • Re: Value objects and Protocol (WL#4760)Alex Esterkin22 May
      • Re: Value objects and Protocol (WL#4760)Brian Aker22 May
        • Re: Value objects and Protocol (WL#4760)Alex Esterkin22 May
          • Re: Value objects and Protocol (WL#4760)Brian Aker22 May
          • Re: Value objects and Protocol (WL#4760)Sergei Golubchik23 May
        • Re: Value objects and Protocol (WL#4760)Konstantin Osipov23 May
          • Re: Value objects and Protocol (WL#4760)Brian Aker23 May
    • Re: Value objects and Protocol (WL#4760)Øystein Grøvlen22 May
      • Re: Value objects and Protocol (WL#4760)Konstantin Osipov22 May
        • Re: Value objects and Protocol (WL#4760)Alex Esterkin22 May
          • Re: Value objects and Protocol (WL#4760)Øystein Grøvlen25 May
        • Re: Value objects and Protocol (WL#4760)Øystein Grøvlen24 May
          • Re: Value objects and Protocol (WL#4760)Konstantin Osipov24 May
      • Re: Value objects and Protocol (WL#4760)Konstantin Osipov23 May
        • Re: Value objects and Protocol (WL#4760)Øystein Grøvlen25 May
          • Re: Value objects and Protocol (WL#4760)Michael Widenius6 Jun
            • Re: Value objects and Protocol (WL#4760)Øystein Grøvlen8 Jun
            • Re: Value objects and Protocol (WL#4760)Jay Pipes8 Jun
              • Re: Value objects and Protocol (WL#4760)Jay Pipes8 Jun
  • Re: Value objects and Protocol (WL#4760)Jay Pipes24 May
    • Re: Value objects and Protocol (WL#4760)Øystein Grøvlen25 May
      • Re: Value objects and Protocol (WL#4760)Jay Pipes26 May
    • Re: [Drizzle-discuss] Value objects and Protocol (WL#4760)Jim Starkey28 May
Re: Value objects and Protocol (WL#4760)Brian Aker22 May