From: Date: July 16 2007 9:38am
Subject: Re: IPV6 data type patch
List-Archive: http://lists.mysql.com/internals/34832
Message-Id: <1184571481.2347.46.camel@dev3-22.dev.cn.tlan>
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

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