This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 155291 - The grab structure doesn't grab exactly the same structure
Summary: The grab structure doesn't grab exactly the same structure
Status: RESOLVED WONTFIX
Alias: None
Product: db
Classification: Unclassified
Component: Code (show other bugs)
Version: 6.x
Hardware: Macintosh Mac OS X
: P2 blocker (vote)
Assignee: Jiri Rechtacek
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-12-12 06:57 UTC by swthomas
Modified: 2009-11-02 11:14 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
BillHistory.grab: Java serialization data, version 5 (1.50 KB, application/octet-stream)
2008-12-12 06:58 UTC, swthomas
Details

Note You need to log in before you can comment on or make changes to this bug.
Description swthomas 2008-12-12 06:57:02 UTC
I've found that the grab structure doesn't grab exactly the same structure, at least against mysql.  For example you have the following table "BillHistory" 
described as follows:
mysql> desc BillHistory;
+-----------+----------------------+------+-----+---------+----------------+
| Field     | Type                 | Null | Key | Default | Extra          |
+-----------+----------------------+------+-----+---------+----------------+
| HistoryID | int(10) unsigned     | NO   | PRI | NULL    | auto_increment |
| BillID    | smallint(5) unsigned | YES  |     | NULL    |                |
| DatePaid  | date                 | YES  |     | NULL    |                |
| TransID   | bigint(20) unsigned  | YES  |     | NULL    |                |
| VendorID  | smallint(5) unsigned | YES  |     | NULL    |                |
+-----------+----------------------+------+-----+---------+----------------+
5 rows in set (0.00 sec)

You grab the structure of this table and create another table, "BillHistory2", using the grabbed structure and you get:

mysql> desc BillHistory2;
+-----------+-------------+------+-----+---------+-------+
| Field     | Type        | Null | Key | Default | Extra |
+-----------+-------------+------+-----+---------+-------+
| HistoryID | int(11)     | NO   | PRI |         |       |
| BillID    | smallint(6) | YES  |     | NULL    |       |
| DatePaid  | date        | YES  |     | NULL    |       |
| TransID   | bigint(20)  | YES  |     | NULL    |       |
| VendorID  | smallint(6) | YES  |     | NULL    |       |
+-----------+-------------+------+-----+---------+-------+
5 rows in set (0.01 sec)

While you can argue that the data size of the fields HistoryID, BillID, VendorID are the same (the unsigned is dropped, but the size is increased) this isn't 
true for TransID.  In BillHistory2 you are now limited to a max value of 2147483647 because it is signed whereas being unsigned in BillHistory you have 
upto 4294967295.  Also, the auto_increment is left out for HistoryID in BillHistory2.

The SQL to create BillHistory is as follows:

create table BillHistory (
  HistoryID     int unsigned auto_increment primary key,
  BillID        smallint unsigned,
  DatePaid      date,
  TransID       bigint unsigned,
  VendorID      smallint unsigned
);

and I'll attached the billhistory grab file that was used to create billhistory2.

Thanks.
Comment 1 swthomas 2008-12-12 06:58:53 UTC
Created attachment 74877 [details]
BillHistory.grab: Java serialization data, version 5
Comment 2 David Vancouvering 2008-12-12 17:35:31 UTC
It sounds like this isn't just annoying, it's broken.  Not sure if we can fix this, but let's try.
Comment 3 David Vancouvering 2008-12-12 17:38:56 UTC
Hi, Rob.  You may not be able to fix this with the current implementation, but take a look.  
Comment 4 Rob Englander 2008-12-12 17:55:17 UTC
I've written a new version of the class that does the work to use the new infrastructure.  But it
currently produces the same output as the old version.

So at least I know where to look.  I guess the issue would be backward compatibility.
Comment 5 Jiri Rechtacek 2009-09-15 10:46:40 UTC
I'm evaluating this...
Comment 6 Jiri Rechtacek 2009-09-15 15:23:32 UTC
I can confirm the problem on NB6.8 too. In virtue of my evaluation the fix will change whole concept of grab/recreate
design, based on JDK mapping JDBC types, unsigned flag is only MySQL extension which hasn't been reflected in JDK1.6
yet. It would break grab/recreate between different platforms. It's not in our current plans but we are going to solve
it later if decided to using DDLUtils library as a replacement of current "grab structure"/"recreate table" model.
Comment 7 Quality Engineering 2009-11-02 11:14:47 UTC
NetBeans.org Migration: changing resolution from LATER to WONTFIX