List:Internals« Previous MessageNext Message »
From:Alex Esterkin Date:May 22 2009 3:51pm
Subject:Re: Value objects and Protocol (WL#4760)
View as plain text  
Konstantin,

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
class.

Regards,

Alex Esterkin

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