You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cayenne.apache.org by Scott Anderson <sa...@airvana.com> on 2008/08/28 19:34:14 UTC

DbMerger/MySQL compatibility

It looks like the DbMerger in 3.0M4 isn't properly detecting whether
NULL is allowed for columns when using MySQL. Is this another issue that
has already been fixed in trunk?

Does it seem reasonable to expect the MySQL adapter to know that MyISAM
doesn't support db-enforced FKs? I don't have the ability to use InnoDB
on one of my target platforms, so DbMerger inevitably complains about
the relationships every time I check the schema.

Regards,
Scott

RE: DbMerger/MySQL compatibility

Posted by Scott Anderson <sa...@airvana.com>.
Woops, hit send too soon on the last email

> Can you try with the latest build?
> http://hudson.zones.apache.org/hudson/job/Cayenne-
> trunk/lastBuild/org.apache.cayenne$cayenne-modeler-java/

Nope; it's not fixed in the latest nightly. Additionally, the same
problem we discussed the other day in regards to Derby is occurring:
ALTER TABLE mail ALTER COLUMN sent SET NOT NULL

This should be:
ALTER TABLE mail CHANGE sent sent timestamp NOT NULL

RE: DbMerger/MySQL compatibility

Posted by Scott Anderson <sa...@airvana.com>.
> Can you try with the latest build?
> http://hudson.zones.apache.org/hudson/job/Cayenne-
> trunk/lastBuild/org.apache.cayenne$cayenne-modeler-java/

Nope; it's not fixed in the latest nightly. Additionally, the same
problem we discussed the other day in regards to Derby is occurring:
ALTER TABLE mail ALTER COLUMN sent SET NOT NULL

This should be:

Re: DbMerger/MySQL compatibility

Posted by Andrus Adamchik <an...@objectstyle.org>.
Not sure if that's helpful at all, but we have a mechanism to detect  
the default table type on a given DB. See MySQLSniffer for details  
("SHOW VARIABLES LIKE 'table_type'"). Maybe not that helpful, as (1)  
it is not using metadata, but rather a MySQL specific command and (2)  
DB default doesn't necessarily means all tables will follow that. I  
have schemas that mix and match InnoDB and MyISAM (for no good reason  
IMO, but still).

Andrus


On Aug 28, 2008, at 10:19 PM, Tore Halset wrote:

>
> On Aug 28, 2008, at 21:03, Scott Anderson wrote:
>
>>> Is it possible to detect this via jdbc?
>>
>> A rather long-winded way to detect table type is:
>> SHOW CREATE TABLE [table name];
>>
>> This will return the full CREATE TABLE instruction required to  
>> rebuild
>> that table. If this is already how you determine what the fields look
>> like, it should be trivial to add logic to parse the ENGINE  
>> parameter.
>
> Currently, I use jdbc metadata only.
>
> - Tore.
>


RE: DbMerger/MySQL compatibility

Posted by Scott Anderson <sa...@airvana.com>.
Disregard the previous email, I spoke too soon. This is looking like a
bug in the MySQL/J driver; it's reporting the field as nullable when it
isn't.

-----Original Message-----
From: Scott Anderson [mailto:sanderson@airvana.com] 
Sent: Friday, September 12, 2008 3:40 PM
To: user@cayenne.apache.org
Subject: RE: DbMerger/MySQL compatibility

In DbLoader.java, circa line 380, there is a reference to the NULLABLE
field. In the ResultSet I'm looking at, there's no such field - there is
however an IS_NULLABLE field.

-----Original Message-----
From: Tore Halset [mailto:halset@pvv.ntnu.no] 
Sent: Thursday, August 28, 2008 3:19 PM
To: user@cayenne.apache.org
Subject: Re: DbMerger/MySQL compatibility


On Aug 28, 2008, at 21:03, Scott Anderson wrote:

>> Is it possible to detect this via jdbc?
>
> A rather long-winded way to detect table type is:
> SHOW CREATE TABLE [table name];
>
> This will return the full CREATE TABLE instruction required to rebuild
> that table. If this is already how you determine what the fields look
> like, it should be trivial to add logic to parse the ENGINE parameter.

Currently, I use jdbc metadata only.

  - Tore.

RE: DbMerger/MySQL compatibility

Posted by Scott Anderson <sa...@airvana.com>.
In DbLoader.java, circa line 380, there is a reference to the NULLABLE
field. In the ResultSet I'm looking at, there's no such field - there is
however an IS_NULLABLE field.

-----Original Message-----
From: Tore Halset [mailto:halset@pvv.ntnu.no] 
Sent: Thursday, August 28, 2008 3:19 PM
To: user@cayenne.apache.org
Subject: Re: DbMerger/MySQL compatibility


On Aug 28, 2008, at 21:03, Scott Anderson wrote:

>> Is it possible to detect this via jdbc?
>
> A rather long-winded way to detect table type is:
> SHOW CREATE TABLE [table name];
>
> This will return the full CREATE TABLE instruction required to rebuild
> that table. If this is already how you determine what the fields look
> like, it should be trivial to add logic to parse the ENGINE parameter.

Currently, I use jdbc metadata only.

  - Tore.

Re: DbMerger/MySQL compatibility

Posted by Tore Halset <ha...@pvv.ntnu.no>.
On Aug 28, 2008, at 21:03, Scott Anderson wrote:

>> Is it possible to detect this via jdbc?
>
> A rather long-winded way to detect table type is:
> SHOW CREATE TABLE [table name];
>
> This will return the full CREATE TABLE instruction required to rebuild
> that table. If this is already how you determine what the fields look
> like, it should be trivial to add logic to parse the ENGINE parameter.

Currently, I use jdbc metadata only.

  - Tore.

RE: DbMerger/MySQL compatibility

Posted by Scott Anderson <sa...@airvana.com>.
> Is it possible to detect this via jdbc?

A rather long-winded way to detect table type is:
SHOW CREATE TABLE [table name];

This will return the full CREATE TABLE instruction required to rebuild
that table. If this is already how you determine what the fields look
like, it should be trivial to add logic to parse the ENGINE parameter.

The query returns in the 'Create Table' field:
CREATE TABLE `group_members` (
  `admin` tinyint(1) NOT NULL default '0',
  `idx` int(11) NOT NULL auto_increment,
  `name` varchar(128) collate latin1_general_cs NOT NULL,
  `active` tinyint(1) NOT NULL default '1',
  PRIMARY KEY  (`idx`),
  UNIQUE KEY `name` (`name`)
) ENGINE=InnoDB AUTO_INCREMENT=8692 DEFAULT CHARSET=latin1
COLLATE=latin1_general_cs

There is probably a simpler way, but I don't know what that is :)

-----Original Message-----
From: Tore Halset [mailto:halset@pvv.ntnu.no] 
Sent: Thursday, August 28, 2008 2:07 PM
To: user@cayenne.apache.org
Subject: Re: DbMerger/MySQL compatibility

On Aug 28, 2008, at 19:34, Scott Anderson wrote:

> It looks like the DbMerger in 3.0M4 isn't properly detecting whether
> NULL is allowed for columns when using MySQL. Is this another issue  
> that
> has already been fixed in trunk?

I do not remember. Can you try with the latest build?
http://hudson.zones.apache.org/hudson/job/Cayenne-trunk/lastBuild/org.ap
ache.cayenne$cayenne-modeler-java/

Unpack cayenne-modeler-java-3.0-SNAPSHOT.jar and run the  
CayenneModeler.jar.
(Why do we have a jar with a jar??

> Does it seem reasonable to expect the MySQL adapter to know that  
> MyISAM
> doesn't support db-enforced FKs? I don't have the ability to use  
> InnoDB
> on one of my target platforms, so DbMerger inevitably complains about
> the relationships every time I check the schema.

Please create a jira for this one. Is it possible to detect this via  
jdbc?

It is not complete, but please log any issues you find, so we can fix  
them. I normally only use PostgreSQL and Derby, so I will detect  
things there first.

Regards,
  - Tore.


Re: DbMerger/MySQL compatibility

Posted by Tore Halset <ha...@pvv.ntnu.no>.
On Aug 28, 2008, at 19:34, Scott Anderson wrote:

> It looks like the DbMerger in 3.0M4 isn't properly detecting whether
> NULL is allowed for columns when using MySQL. Is this another issue  
> that
> has already been fixed in trunk?

I do not remember. Can you try with the latest build?
http://hudson.zones.apache.org/hudson/job/Cayenne-trunk/lastBuild/org.apache.cayenne$cayenne-modeler-java/

Unpack cayenne-modeler-java-3.0-SNAPSHOT.jar and run the  
CayenneModeler.jar.
(Why do we have a jar with a jar??

> Does it seem reasonable to expect the MySQL adapter to know that  
> MyISAM
> doesn't support db-enforced FKs? I don't have the ability to use  
> InnoDB
> on one of my target platforms, so DbMerger inevitably complains about
> the relationships every time I check the schema.

Please create a jira for this one. Is it possible to detect this via  
jdbc?

It is not complete, but please log any issues you find, so we can fix  
them. I normally only use PostgreSQL and Derby, so I will detect  
things there first.

Regards,
  - Tore.