Re: IPV6 data type patch

[Milos Prodanovic]

On 7/16/07, David Li <david.li@stripped> 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.