Pantek Library
Hosting Provided By
CybrHost
High Speed Hosting

Re: IPV6 data type patch

From: Milos Prodanovic <milos.prodanovic(at)gmail.com>
Date: Tue Jul 17 2007 - 10:05:31 EDT


On 7/16/07, David Li <david.li@mysql.com> wrote:
> Hi Stewart,
>
> > On Mon, 2007-07-16 at 06:04 +0000, Milos Prodanovic wrote:
> > > Down below you can find IPV6 data type patch, as result of Google Summer of Code
> > > midterm milestone.
> >
> > Disclaimer: I haven't read through the whole patch.
> >
> > One thing to consider is endian compatibility.
> >
> > On disk format (for local disk engines) should be compatible... is this
> > so? are you always storing these types in network byte order (surely the
> > simplest)?
> >
> > This extends into more fun for NDB with the endian compatibility
> > patches. I've CC'd David who's been working on this.
> >
> > For NDB with endian compatibility... a SQL node could store a value into
> > the cluster and an SQL node with a different byte order could read it..
> > The value should, of course, make sense to the other node.
> >
> > David can probably better comment.... this is possibly the same issue
> > with GIS data for NDB.
> >
>
> I read the patch quickly and found that it set the newly added
> data types to Binary in NDB engine, so I think they can be treated
> as Binary data type in the endian compatibility patches.
>
> Yes, I think it's the same issue with GIS data for NDB (where
> the GIS data types are treated as Blob in NDB internal).
>
> And I think they maybe will not cause big problems to endian
> compatibility patches.
>
> I pasted the related part of the patch here:
>
> --- mysql-5.1.19-beta/sql/ha_ndbcluster.cc 2007-05-26
> 10:19:02.000000000 +0000
> +++ mysql-5.1.19-beta_new/sql/ha_ndbcluster.cc 2007-05-26
> 10:18:59.000000000 +0000
> @@ -4797,6 +4801,13 @@
> col.setType(NDBCOL::Timestamp);
> col.setLength(1);
> break;
> + case MYSQL_TYPE_EUI64:
> + case MYSQL_TYPE_MAC48:
> + case MYSQL_TYPE_IPV4:
> + case MYSQL_TYPE_IPV6:
> + col.setType(NDBCOL::Binary);
> + col.setLength(field->pack_length());
> + break;
>
>
> Best regards,
>
> David
>
>
> > Also, a spec of how things are stored would be great - means that people
> > should be able to use the IP types in a compatible way from NDBAPI
> > applications (which have no MySQL Server code in them... so a data type
> > added inside the SQL server is unknown to an NDB API application).
>
>
>

With portability in mind I've created proprietary mysql internal inet functions for parsing and representation of addresses. Data that is stored is not stored in network order, nor have any interaction with system network functions, nor it depends on libc. I've considered network data types as blob or as a string.

IPv4 address 192.168.1.1 is internally stored as 4xbyte (or uin32) char *ptr="\192\168\1\1"
and IPv6 address aabb:ccdd:dead:beef:1234:4321:a1b2:c3d4 is internally stored as 16xbyte
char *ptr="\xaa\xbb\xcc\xdd\xde\xad\xbe\xef\12\x34\x43\x21\xa1\xb2\xc3\xd4";

Data type uses STRING_RESULT as result type, and where charset is needed for some function, my_charset_bin is used.

To be able to do my GSoC project and In order to better understand how things are done in MySQL I've tried to find and understand code on each place that string type or blob type is questioned in the mysql code. I've tried to understand what the code is 'doing' and what was decision based on mysql type (what are consequences).

That doesn't mean that I've grasped correctly all occurrences correctly, but I can
post my report file where I've wrote what files was under examination, and what I've decided when I was rendering MySQL code. Reports are like "should I change it , or should it stay the way it is, and why I've done this way". I didn't want to
put lot of comments on places that I've just inserted "case MYSQL_TYPE_IPV6", so I've stored comments in separate file.

I will try to get closer look on NDBAPI.

It would be nice to make some functionality tests, and I'm not sure that I can make
tests of all possible 'use cases', but I'm glad to do tests if you have some crucial test
that could show usability.

-- 
MySQL Internals Mailing List
For list archives: 
http://lists.mysql.com/internals
To unsubscribe:    
http://lists.mysql.com/internals?unsub=lists@pantek.com
Received on Tue Jul 17 10:05:51 2007
Do you need help?X

This archive was generated by hypermail 2.1.8 : Thu Aug 09 2007 - 19:06:17 EDT


Contact Us  Legal Notices  Order Services Online 
Pantek Home  Privacy Policy  IT news  Site Map  Pantek Library