You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cayenne.apache.org by Tobias SCHOESSLER <To...@unvienna.org> on 2006/08/28 11:22:22 UTC
Problems with MySql id type with AUTO_INCREMENT
I use cayenne 1.2, MySql. AUTO_INCREMENT ids
the type of the id field in the mysql schema is set to
INT NOT NULL AUTO_INCREMENT UNIQUE
I create an object of this table with cayenne and commit. I see the row
inserted ok. When accessing the Id of the object via
getObjectId().getIdSnapshot().get(this.FOLDER_UID_PK_COLUMN)
in the same DataContext the type of the Object retruned is a Long. (Though
I would have expected it to be an Integer from the MySql jdbc
documentation)
When I use a fresh DataContext and retrieve the same row the id object
returned by
getObjectId().getIdSnapshot().get(this.FOLDER_UID_PK_COLUMN)
seems to be an Integer ?
I tried to set the type to
INT UNSIGNED NOT NULL AUTO_INCREMENT UNIQUE
which is supposed to be of Long type from the jdbc type documentation of
MySql.
to force the id object always to be a Long but cayenne still returns an
Integer when reading from the db.
any ideas?
thanks
Re: Problems with MySql id type with AUTO_INCREMENT
Posted by Tobias SCHOESSLER <To...@unvienna.org>.
Sorry,the problem with the sequoia jdbc driver returning Integer Type for
the PK as described below is solved. It was not an issue of cayenne at all.
There were some problem with the update of the schema. sequoia worked with
the old INT UNSIGNED schema tested earlier.
So MySQL 5, Sequoia, db side AUTO_INCREMENT PK using BIGINT and
java.lang.Long mapping seem to work too.
Tobias.Schoessler
@unvienna.org
To
Friday, 29 cayenne-user@incubator.apache.org,
September 2006 cayenne-user@incubator.apache.org
20:39 cc
Subject
Please respond to Re: Problems with MySql id type
cayenne-user@incu with AUTO_INCREMENT
bator.apache.org
ah ok, thanks for clarifying this.
was this MySQL no Locking PkGenerator ever implemented?
*
Hmm, I got so far with the AUTO_INCREMENT set up, I don't want to drop it
so quickly.
>From reading the Sequoia docs I don't get why the sequoia jdbc driver
returns different meta data than the 'slave' mysql jdbc driver. Especially
if I use a jdbc based tool to lookup the metadata through the Sequoia jdbc
driver I see correct meta data for the pk column reading BIGINT.
In an earlier post you said you found
org.apache.cayenne.access.jdbc.ColumnDescriptor beeing responsible for
SQLTemplate to retrieve an Integer PK. At that time I was using INT
UNSIGNED and direct Mysql connection. I then changed the PK type to BIGINT,
which fixed the issue.
With Sequoia it now seems to be similar. Everything works fine except the
SQLTemplate test case.
I understand it is difficult to add a Sequoia setup to your test cases, but
could you give me a hint how I could test the
org.apache.cayenne.access.jdbc.ColumnDescriptor Bug with Sequoia myself so
I can make sure sequoia is to blame?
Tobias
Andrus Adamchik <an...@objectstyle.org> wrote:
Yeah, there is quite a few bugs involved.
First an explanation on Cayenne strategies... Long works with
auto_increment as long as the driver supports it, but doesn't not
work with any other strategy, as all of them are based on overriding
"int JdbcPkGenerator.pkFromDatabase(..)".
What we can do about it now... The simplest way seems to use INT PK
with "auto_pk_table" generation strategy and a custom PkGenerator
that doesn't perform locking.
Here is a mailing list thread on implementing an "optimistic" pk for
MySQL:
http://objectstyle.org/cayenne/lists/cayenne-user/2006/07/0067.html
Wouldn't mind including this in Cayenne at some point.
Andrus
On Sep 29, 2006, at 11:03 AM, Tobias SCHOESSLER wrote:
> I am a bit confused now ... so java.lang.Long PKs are known to not
> work at
> all with cayenne 1.2 no matter which database is used?
>
> I had the impression everything worked fine when using MySQL
> directly with
> BIGINT, Long and database side AUTO_INCREMENT.
>
> My last bug I ran into was only when I connected through the
> sequoia jdbc
> driver / mysql jdbc driver chain when the test case broke again ...
>
> Anyway I am flexible with the pk column types but because of this
> MySql
> jdbc driver bug mentioned before
>
> http://lists.mysql.com/java/6383
>
> - returning meta data of type java.lang.Long for any AUTO_INCREMENT
> column
> defined -
>
> I thought I was forced to use some database type that consistently
> maps as
> java.lang.Long for the PK to not have to deal with changing pk
> types on
> creation and retrieval . That's why i tried INT UNSIGNED and BIGINT.
>
> Is your advise still correct for this ?
>
>
>
>
>
>
> Andrus Adamchik
> <andrus@objectsty
>
> le.org> To
> cayenne-
> user@incubator.apache.org
> Friday,
> 29 cc
> September 2006
> 15:57
> Subject
> Re: Problems with MySql id type
> with AUTO_INCREMENT
> Please respond to
> cayenne-user@incu
> bator.apache.org
>
>
>
>
>
>
>
> Tobias,
>
> If you have flexibility redefining your columns, I suggest mapping a
> PK as INTEGER until we implement Long PK support for real (http://
> issues.apache.org/cayenne/browse/CAY-329). As far as I can tell in
> the your latest case you are hitting the int pk limitation of PK
> generator. This issue is pretty high on our priority list by the way,
> so Long pks should become an option soon.
>
> Andrus
>
>
> On Sep 29, 2006, at 9:51 AM, Tobias SCHOESSLER wrote:
>
>> Andrus, thanks a lot you for looking into this.
>>
>> That is quite a pile of bugs I am running into here. First this
>> MySQL JDBC
>> driver bug returning java.lang.Long for any auto-increment column,
>> then
>> cayenne treating 'INT UNSIGNED' as an Integer. Now issues with
>> org.apache.cayenne.access.jdbc.ColumnDescriptor and SQLTemplate.
>>
>> To get this running for me I understand that I only have to pick
>> the right
>> datatype for my PKs so all the bugs are bypassed. Looking at
>> http://dev.mysql.com/doc/refman/5.0/en/connector-j-reference-type-
>> conversions.html
>> I thought BIGINT should be unambigiously treated as a
>> java.lang.Long for
>> all bugs mentioned.
>>
>> Actually it worked, I tried setting the PKs to mysql type BIGINT
>> and the
>> test case mentioned below passes. So for the record this is a
>> solution for
>> using AUTO_INCREMENT PK generation with cayenne 1.2 and MySQL.
>>
>> But...
>>
>> If you recall my ultimate goal was to use a setup in which MySql is
>> used in
>> a Sequoia/CJDBC cluster - the reason I did not use AUTO_PK_SUPPORT
>> as LOCK
>> was not supported by Sequoia ...
>>
>> Connecting through the cjdbc/sequoia driver to the database above,
>> again
>> breaks the test case. Sequoia returns java.lang.Integer for the
>> BIGINT
>> column ... : -[
>>
>> I guess this is rather something to address in a sequoia forum or
>> is there
>> a chance you add a sequoia setup in your test cases?
>>
>> thanks
>>
>> Tobias
>>
>>
>>
>>
>> Andrus Adamchik
>> <andrus@objectsty
>>
>> le.org> To
>> cayenne-
>> user@incubator.apache.org
>> Thursday,
>> 28 cc
>> September 2006
>> 17:44
>> Subject
>> Re: Problems with MySql id
>> type
>> with AUTO_INCREMENT
>> Please respond to
>> cayenne-user@incu
>> bator.apache.org
>>
>>
>>
>>
>>
>>
>>
>> Just got some time to test it, and the problem seems to be in
>> org.apache.cayenne.access.jdbc.ColumnDescriptor constructor... It is
>> getting confused by MySQL ResultSetMetaData returning JDBC type for
>> such column as INTEGER.
>>
>> I created a new Jira issue with description of this problem:
>>
>> http://issues.apache.org/cayenne/browse/CAY-672
>>
>> I'll commit a fix to 3.0, as 1.2 users can have some code relying on
>> the old behavior and we want to keep 1.2 stable.
>>
>> Andrus
>>
>>
>> On Sep 26, 2006, at 7:11 AM, Tobias SCHOESSLER wrote:
>>> Andrus,
>>>
>>> I am referring to http://issues.apache.org/cayenne/browse/CAY-639
>>> and our
>>> discussion below.
>>>
>>> I am using cayenne 1.2.1 now. I mapped all AUTO_INCREMENTED primary
>>> keys of
>>> sql type unsigned int as BIG_INT in cayenne.
>>>
>>> Cayenne correctly returns DataObjects with a primary key of type
>>> Long when
>>> using SelectQuery, when creating new objects or using getToXXX
>>> navigation
>>> to retrieve the object .
>>>
>>> But when I use SQLTemplate to retrieve the same DataObject cayenne
>>> still
>>> returns a pk of type Integer ...
>>>
>>> These are my test cases:
>>>
>>>
>>> public void testDocumentPkViaSelectQuery() {
>>> List<TldDocument> docList =
>>> dataContext.performQuery(new
>>> SelectQuery(TldDocument.class, null));
>>> assertEquals(Long.class,
>>> docList.get(0).getObjectId().getIdSnapshot().get
>>> (TldDocument.DOCUMENT_UID_PK_COLUMN).getClass());
>>>
>>> }
>>>
>>> public void testDocumentPkViaSQLTemplate() {
>>>
>>> String sqlSelect = " select * ";
>>> String sqlFrom = " from TLD_DOCUMENT doc ";
>>>
>>> SQLTemplate query = new SQLTemplate
>>> (TldDocument.class,
>>> sqlSelect + " " + sqlFrom);
>>> List<TldDocument> docList =
>>> dataContext.performQuery(query);
>>>
>>> assertEquals(Long.class,
>>> docList.get(0).getObjectId().getIdSnapshot().get
>>> (TldDocument.DOCUMENT_UID_PK_COLUMN).getClass());
>>>
>>> }
>>>
>>> testDocumentPkViaSelectQuery passes.
>>>
>>> testDocumentPkViaSQLTemplate fails.
>>>
>>> thanks, regards
>>>
>>> Tobias.
>>>
>>>
>>>
>>>
>>>
>>> Andrus Adamchik
>>> <andrus@objectsty
>>>
>>> le.org> To
>>> cayenne-
>>> user@incubator.apache.org
>>> Tuesday,
>>> 29 cc
>>> August 2006 15:35
>>>
>>> Subject
>>> Re: Problems with MySql id
>>> type
>>> Please respond to with AUTO_INCREMENT
>>> cayenne-user@incu
>>> bator.apache.org
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> I'd appreciate that.
>>>
>>> Andrus
>>>
>>>
>>> On Aug 29, 2006, at 5:31 PM, Tobias SCHOESSLER wrote:
>>>
>>>> ok, I got it. You want me to add a Jira entry for this? I never did
>>>> this
>>>> before ... : |
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Andrus Adamchik
>>>> <andrus@objectsty
>>>>
>>>> le.org> To
>>>> cayenne-
>>>> user@incubator.apache.org
>>>> Tuesday,
>>>> 29 cc
>>>> August 2006 15:19
>>>>
>>>> Subject
>>>> Re: Problems with MySql id
>>>> type
>>>> Please respond to with AUTO_INCREMENT
>>>> cayenne-user@incu
>>>> bator.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Aug 29, 2006, at 4:16 PM, Tobias SCHOESSLER wrote:
>>>>
>>>>> But still you are right there is a bug in mysql too. If the column
>>>>> type is
>>>>> INT and not INT UNSIGNED it should return java.lang.Integer but it
>>>>> returns
>>>>> java.lang.Long instead. This was my first observation.
>>>>
>>>> Still probably worth fixing the mapping to follow the docs.
>>>>
>>>>
>>>>> but why does cayenne need BIGINT mapping set for the column to
>>>>> retrieve it
>>>>> as a java.lang.Long? I understand that this is unrelated to the
>>>>> bug
>>>>> in the
>>>>> mysql jdbc driver mentioned above.
>>>>
>>>> This is simply a workaround for the bug. BIGINT has a default JDBC
>>>> mapping to java.lang.Long. So this consistently produced a Long
>>>> during select and when reading auto-incremented value via JDBC.
>>>>
>>>> Andrus
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>
>
>
___
sent via WebmailLight 3.1.11
Re: Problems with MySql id type with AUTO_INCREMENT
Posted by To...@unvienna.org.
ah ok, thanks for clarifying this.
was this MySQL no Locking PkGenerator ever implemented?
*
Hmm, I got so far with the AUTO_INCREMENT set up, I don't want to drop it so quickly.
>From reading the Sequoia docs I don't get why the sequoia jdbc driver returns different meta data than the 'slave' mysql jdbc driver. Especially if I use a jdbc based tool to lookup the metadata through the Sequoia jdbc driver I see correct meta data for the pk column reading BIGINT.
In an earlier post you said you found org.apache.cayenne.access.jdbc.ColumnDescriptor beeing responsible for SQLTemplate to retrieve an Integer PK. At that time I was using INT UNSIGNED and direct Mysql connection. I then changed the PK type to BIGINT, which fixed the issue.
With Sequoia it now seems to be similar. Everything works fine except the SQLTemplate test case.
I understand it is difficult to add a Sequoia setup to your test cases, but could you give me a hint how I could test the org.apache.cayenne.access.jdbc.ColumnDescriptor Bug with Sequoia myself so I can make sure sequoia is to blame?
Tobias
Andrus Adamchik <an...@objectstyle.org> wrote:
Yeah, there is quite a few bugs involved.
First an explanation on Cayenne strategies... Long works with
auto_increment as long as the driver supports it, but doesn't not
work with any other strategy, as all of them are based on overriding
"int JdbcPkGenerator.pkFromDatabase(..)".
What we can do about it now... The simplest way seems to use INT PK
with "auto_pk_table" generation strategy and a custom PkGenerator
that doesn't perform locking.
Here is a mailing list thread on implementing an "optimistic" pk for
MySQL:
http://objectstyle.org/cayenne/lists/cayenne-user/2006/07/0067.html
Wouldn't mind including this in Cayenne at some point.
Andrus
On Sep 29, 2006, at 11:03 AM, Tobias SCHOESSLER wrote:
> I am a bit confused now ... so java.lang.Long PKs are known to not
> work at
> all with cayenne 1.2 no matter which database is used?
>
> I had the impression everything worked fine when using MySQL
> directly with
> BIGINT, Long and database side AUTO_INCREMENT.
>
> My last bug I ran into was only when I connected through the
> sequoia jdbc
> driver / mysql jdbc driver chain when the test case broke again ...
>
> Anyway I am flexible with the pk column types but because of this
> MySql
> jdbc driver bug mentioned before
>
> http://lists.mysql.com/java/6383
>
> - returning meta data of type java.lang.Long for any AUTO_INCREMENT
> column
> defined -
>
> I thought I was forced to use some database type that consistently
> maps as
> java.lang.Long for the PK to not have to deal with changing pk
> types on
> creation and retrieval . That's why i tried INT UNSIGNED and BIGINT.
>
> Is your advise still correct for this ?
>
>
>
>
>
>
> Andrus Adamchik
> <andrus@objectsty
>
> le.org> To
> cayenne-
> user@incubator.apache.org
> Friday,
> 29 cc
> September 2006
> 15:57
> Subject
> Re: Problems with MySql id type
> with AUTO_INCREMENT
> Please respond to
> cayenne-user@incu
> bator.apache.org
>
>
>
>
>
>
>
> Tobias,
>
> If you have flexibility redefining your columns, I suggest mapping a
> PK as INTEGER until we implement Long PK support for real (http://
> issues.apache.org/cayenne/browse/CAY-329). As far as I can tell in
> the your latest case you are hitting the int pk limitation of PK
> generator. This issue is pretty high on our priority list by the way,
> so Long pks should become an option soon.
>
> Andrus
>
>
> On Sep 29, 2006, at 9:51 AM, Tobias SCHOESSLER wrote:
>
>> Andrus, thanks a lot you for looking into this.
>>
>> That is quite a pile of bugs I am running into here. First this
>> MySQL JDBC
>> driver bug returning java.lang.Long for any auto-increment column,
>> then
>> cayenne treating 'INT UNSIGNED' as an Integer. Now issues with
>> org.apache.cayenne.access.jdbc.ColumnDescriptor and SQLTemplate.
>>
>> To get this running for me I understand that I only have to pick
>> the right
>> datatype for my PKs so all the bugs are bypassed. Looking at
>> http://dev.mysql.com/doc/refman/5.0/en/connector-j-reference-type-
>> conversions.html
>> I thought BIGINT should be unambigiously treated as a
>> java.lang.Long for
>> all bugs mentioned.
>>
>> Actually it worked, I tried setting the PKs to mysql type BIGINT
>> and the
>> test case mentioned below passes. So for the record this is a
>> solution for
>> using AUTO_INCREMENT PK generation with cayenne 1.2 and MySQL.
>>
>> But...
>>
>> If you recall my ultimate goal was to use a setup in which MySql is
>> used in
>> a Sequoia/CJDBC cluster - the reason I did not use AUTO_PK_SUPPORT
>> as LOCK
>> was not supported by Sequoia ...
>>
>> Connecting through the cjdbc/sequoia driver to the database above,
>> again
>> breaks the test case. Sequoia returns java.lang.Integer for the
>> BIGINT
>> column ... : -[
>>
>> I guess this is rather something to address in a sequoia forum or
>> is there
>> a chance you add a sequoia setup in your test cases?
>>
>> thanks
>>
>> Tobias
>>
>>
>>
>>
>> Andrus Adamchik
>> <andrus@objectsty
>>
>> le.org> To
>> cayenne-
>> user@incubator.apache.org
>> Thursday,
>> 28 cc
>> September 2006
>> 17:44
>> Subject
>> Re: Problems with MySql id
>> type
>> with AUTO_INCREMENT
>> Please respond to
>> cayenne-user@incu
>> bator.apache.org
>>
>>
>>
>>
>>
>>
>>
>> Just got some time to test it, and the problem seems to be in
>> org.apache.cayenne.access.jdbc.ColumnDescriptor constructor... It is
>> getting confused by MySQL ResultSetMetaData returning JDBC type for
>> such column as INTEGER.
>>
>> I created a new Jira issue with description of this problem:
>>
>> http://issues.apache.org/cayenne/browse/CAY-672
>>
>> I'll commit a fix to 3.0, as 1.2 users can have some code relying on
>> the old behavior and we want to keep 1.2 stable.
>>
>> Andrus
>>
>>
>> On Sep 26, 2006, at 7:11 AM, Tobias SCHOESSLER wrote:
>>> Andrus,
>>>
>>> I am referring to http://issues.apache.org/cayenne/browse/CAY-639
>>> and our
>>> discussion below.
>>>
>>> I am using cayenne 1.2.1 now. I mapped all AUTO_INCREMENTED primary
>>> keys of
>>> sql type unsigned int as BIG_INT in cayenne.
>>>
>>> Cayenne correctly returns DataObjects with a primary key of type
>>> Long when
>>> using SelectQuery, when creating new objects or using getToXXX
>>> navigation
>>> to retrieve the object .
>>>
>>> But when I use SQLTemplate to retrieve the same DataObject cayenne
>>> still
>>> returns a pk of type Integer ...
>>>
>>> These are my test cases:
>>>
>>>
>>> public void testDocumentPkViaSelectQuery() {
>>> List<TldDocument> docList =
>>> dataContext.performQuery(new
>>> SelectQuery(TldDocument.class, null));
>>> assertEquals(Long.class,
>>> docList.get(0).getObjectId().getIdSnapshot().get
>>> (TldDocument.DOCUMENT_UID_PK_COLUMN).getClass());
>>>
>>> }
>>>
>>> public void testDocumentPkViaSQLTemplate() {
>>>
>>> String sqlSelect = " select * ";
>>> String sqlFrom = " from TLD_DOCUMENT doc ";
>>>
>>> SQLTemplate query = new SQLTemplate
>>> (TldDocument.class,
>>> sqlSelect + " " + sqlFrom);
>>> List<TldDocument> docList =
>>> dataContext.performQuery(query);
>>>
>>> assertEquals(Long.class,
>>> docList.get(0).getObjectId().getIdSnapshot().get
>>> (TldDocument.DOCUMENT_UID_PK_COLUMN).getClass());
>>>
>>> }
>>>
>>> testDocumentPkViaSelectQuery passes.
>>>
>>> testDocumentPkViaSQLTemplate fails.
>>>
>>> thanks, regards
>>>
>>> Tobias.
>>>
>>>
>>>
>>>
>>>
>>> Andrus Adamchik
>>> <andrus@objectsty
>>>
>>> le.org> To
>>> cayenne-
>>> user@incubator.apache.org
>>> Tuesday,
>>> 29 cc
>>> August 2006 15:35
>>>
>>> Subject
>>> Re: Problems with MySql id
>>> type
>>> Please respond to with AUTO_INCREMENT
>>> cayenne-user@incu
>>> bator.apache.org
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> I'd appreciate that.
>>>
>>> Andrus
>>>
>>>
>>> On Aug 29, 2006, at 5:31 PM, Tobias SCHOESSLER wrote:
>>>
>>>> ok, I got it. You want me to add a Jira entry for this? I never did
>>>> this
>>>> before ... : |
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Andrus Adamchik
>>>> <andrus@objectsty
>>>>
>>>> le.org> To
>>>> cayenne-
>>>> user@incubator.apache.org
>>>> Tuesday,
>>>> 29 cc
>>>> August 2006 15:19
>>>>
>>>> Subject
>>>> Re: Problems with MySql id
>>>> type
>>>> Please respond to with AUTO_INCREMENT
>>>> cayenne-user@incu
>>>> bator.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Aug 29, 2006, at 4:16 PM, Tobias SCHOESSLER wrote:
>>>>
>>>>> But still you are right there is a bug in mysql too. If the column
>>>>> type is
>>>>> INT and not INT UNSIGNED it should return java.lang.Integer but it
>>>>> returns
>>>>> java.lang.Long instead. This was my first observation.
>>>>
>>>> Still probably worth fixing the mapping to follow the docs.
>>>>
>>>>
>>>>> but why does cayenne need BIGINT mapping set for the column to
>>>>> retrieve it
>>>>> as a java.lang.Long? I understand that this is unrelated to the
>>>>> bug
>>>>> in the
>>>>> mysql jdbc driver mentioned above.
>>>>
>>>> This is simply a workaround for the bug. BIGINT has a default JDBC
>>>> mapping to java.lang.Long. So this consistently produced a Long
>>>> during select and when reading auto-incremented value via JDBC.
>>>>
>>>> Andrus
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>
>
>
___
sent via WebmailLight 3.1.11
Re: Problems with MySql id type with AUTO_INCREMENT
Posted by Andrus Adamchik <an...@objectstyle.org>.
Yeah, there is quite a few bugs involved.
First an explanation on Cayenne strategies... Long works with
auto_increment as long as the driver supports it, but doesn't not
work with any other strategy, as all of them are based on overriding
"int JdbcPkGenerator.pkFromDatabase(..)".
What we can do about it now... The simplest way seems to use INT PK
with "auto_pk_table" generation strategy and a custom PkGenerator
that doesn't perform locking.
Here is a mailing list thread on implementing an "optimistic" pk for
MySQL:
http://objectstyle.org/cayenne/lists/cayenne-user/2006/07/0067.html
Wouldn't mind including this in Cayenne at some point.
Andrus
On Sep 29, 2006, at 11:03 AM, Tobias SCHOESSLER wrote:
> I am a bit confused now ... so java.lang.Long PKs are known to not
> work at
> all with cayenne 1.2 no matter which database is used?
>
> I had the impression everything worked fine when using MySQL
> directly with
> BIGINT, Long and database side AUTO_INCREMENT.
>
> My last bug I ran into was only when I connected through the
> sequoia jdbc
> driver / mysql jdbc driver chain when the test case broke again ...
>
> Anyway I am flexible with the pk column types but because of this
> MySql
> jdbc driver bug mentioned before
>
> http://lists.mysql.com/java/6383
>
> - returning meta data of type java.lang.Long for any AUTO_INCREMENT
> column
> defined -
>
> I thought I was forced to use some database type that consistently
> maps as
> java.lang.Long for the PK to not have to deal with changing pk
> types on
> creation and retrieval . That's why i tried INT UNSIGNED and BIGINT.
>
> Is your advise still correct for this ?
>
>
>
>
>
>
> Andrus Adamchik
> <andrus@objectsty
>
> le.org> To
> cayenne-
> user@incubator.apache.org
> Friday,
> 29 cc
> September 2006
> 15:57
> Subject
> Re: Problems with MySql id type
> with AUTO_INCREMENT
> Please respond to
> cayenne-user@incu
> bator.apache.org
>
>
>
>
>
>
>
> Tobias,
>
> If you have flexibility redefining your columns, I suggest mapping a
> PK as INTEGER until we implement Long PK support for real (http://
> issues.apache.org/cayenne/browse/CAY-329). As far as I can tell in
> the your latest case you are hitting the int pk limitation of PK
> generator. This issue is pretty high on our priority list by the way,
> so Long pks should become an option soon.
>
> Andrus
>
>
> On Sep 29, 2006, at 9:51 AM, Tobias SCHOESSLER wrote:
>
>> Andrus, thanks a lot you for looking into this.
>>
>> That is quite a pile of bugs I am running into here. First this
>> MySQL JDBC
>> driver bug returning java.lang.Long for any auto-increment column,
>> then
>> cayenne treating 'INT UNSIGNED' as an Integer. Now issues with
>> org.apache.cayenne.access.jdbc.ColumnDescriptor and SQLTemplate.
>>
>> To get this running for me I understand that I only have to pick
>> the right
>> datatype for my PKs so all the bugs are bypassed. Looking at
>> http://dev.mysql.com/doc/refman/5.0/en/connector-j-reference-type-
>> conversions.html
>> I thought BIGINT should be unambigiously treated as a
>> java.lang.Long for
>> all bugs mentioned.
>>
>> Actually it worked, I tried setting the PKs to mysql type BIGINT
>> and the
>> test case mentioned below passes. So for the record this is a
>> solution for
>> using AUTO_INCREMENT PK generation with cayenne 1.2 and MySQL.
>>
>> But...
>>
>> If you recall my ultimate goal was to use a setup in which MySql is
>> used in
>> a Sequoia/CJDBC cluster - the reason I did not use AUTO_PK_SUPPORT
>> as LOCK
>> was not supported by Sequoia ...
>>
>> Connecting through the cjdbc/sequoia driver to the database above,
>> again
>> breaks the test case. Sequoia returns java.lang.Integer for the
>> BIGINT
>> column ... : -[
>>
>> I guess this is rather something to address in a sequoia forum or
>> is there
>> a chance you add a sequoia setup in your test cases?
>>
>> thanks
>>
>> Tobias
>>
>>
>>
>>
>> Andrus Adamchik
>> <andrus@objectsty
>>
>> le.org> To
>> cayenne-
>> user@incubator.apache.org
>> Thursday,
>> 28 cc
>> September 2006
>> 17:44
>> Subject
>> Re: Problems with MySql id
>> type
>> with AUTO_INCREMENT
>> Please respond to
>> cayenne-user@incu
>> bator.apache.org
>>
>>
>>
>>
>>
>>
>>
>> Just got some time to test it, and the problem seems to be in
>> org.apache.cayenne.access.jdbc.ColumnDescriptor constructor... It is
>> getting confused by MySQL ResultSetMetaData returning JDBC type for
>> such column as INTEGER.
>>
>> I created a new Jira issue with description of this problem:
>>
>> http://issues.apache.org/cayenne/browse/CAY-672
>>
>> I'll commit a fix to 3.0, as 1.2 users can have some code relying on
>> the old behavior and we want to keep 1.2 stable.
>>
>> Andrus
>>
>>
>> On Sep 26, 2006, at 7:11 AM, Tobias SCHOESSLER wrote:
>>> Andrus,
>>>
>>> I am referring to http://issues.apache.org/cayenne/browse/CAY-639
>>> and our
>>> discussion below.
>>>
>>> I am using cayenne 1.2.1 now. I mapped all AUTO_INCREMENTED primary
>>> keys of
>>> sql type unsigned int as BIG_INT in cayenne.
>>>
>>> Cayenne correctly returns DataObjects with a primary key of type
>>> Long when
>>> using SelectQuery, when creating new objects or using getToXXX
>>> navigation
>>> to retrieve the object .
>>>
>>> But when I use SQLTemplate to retrieve the same DataObject cayenne
>>> still
>>> returns a pk of type Integer ...
>>>
>>> These are my test cases:
>>>
>>>
>>> public void testDocumentPkViaSelectQuery() {
>>> List<TldDocument> docList =
>>> dataContext.performQuery(new
>>> SelectQuery(TldDocument.class, null));
>>> assertEquals(Long.class,
>>> docList.get(0).getObjectId().getIdSnapshot().get
>>> (TldDocument.DOCUMENT_UID_PK_COLUMN).getClass());
>>>
>>> }
>>>
>>> public void testDocumentPkViaSQLTemplate() {
>>>
>>> String sqlSelect = " select * ";
>>> String sqlFrom = " from TLD_DOCUMENT doc ";
>>>
>>> SQLTemplate query = new SQLTemplate
>>> (TldDocument.class,
>>> sqlSelect + " " + sqlFrom);
>>> List<TldDocument> docList =
>>> dataContext.performQuery(query);
>>>
>>> assertEquals(Long.class,
>>> docList.get(0).getObjectId().getIdSnapshot().get
>>> (TldDocument.DOCUMENT_UID_PK_COLUMN).getClass());
>>>
>>> }
>>>
>>> testDocumentPkViaSelectQuery passes.
>>>
>>> testDocumentPkViaSQLTemplate fails.
>>>
>>> thanks, regards
>>>
>>> Tobias.
>>>
>>>
>>>
>>>
>>>
>>> Andrus Adamchik
>>> <andrus@objectsty
>>>
>>> le.org> To
>>> cayenne-
>>> user@incubator.apache.org
>>> Tuesday,
>>> 29 cc
>>> August 2006 15:35
>>>
>>> Subject
>>> Re: Problems with MySql id
>>> type
>>> Please respond to with AUTO_INCREMENT
>>> cayenne-user@incu
>>> bator.apache.org
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> I'd appreciate that.
>>>
>>> Andrus
>>>
>>>
>>> On Aug 29, 2006, at 5:31 PM, Tobias SCHOESSLER wrote:
>>>
>>>> ok, I got it. You want me to add a Jira entry for this? I never did
>>>> this
>>>> before ... : |
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Andrus Adamchik
>>>> <andrus@objectsty
>>>>
>>>> le.org> To
>>>> cayenne-
>>>> user@incubator.apache.org
>>>> Tuesday,
>>>> 29 cc
>>>> August 2006 15:19
>>>>
>>>> Subject
>>>> Re: Problems with MySql id
>>>> type
>>>> Please respond to with AUTO_INCREMENT
>>>> cayenne-user@incu
>>>> bator.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Aug 29, 2006, at 4:16 PM, Tobias SCHOESSLER wrote:
>>>>
>>>>> But still you are right there is a bug in mysql too. If the column
>>>>> type is
>>>>> INT and not INT UNSIGNED it should return java.lang.Integer but it
>>>>> returns
>>>>> java.lang.Long instead. This was my first observation.
>>>>
>>>> Still probably worth fixing the mapping to follow the docs.
>>>>
>>>>
>>>>> but why does cayenne need BIGINT mapping set for the column to
>>>>> retrieve it
>>>>> as a java.lang.Long? I understand that this is unrelated to the
>>>>> bug
>>>>> in the
>>>>> mysql jdbc driver mentioned above.
>>>>
>>>> This is simply a workaround for the bug. BIGINT has a default JDBC
>>>> mapping to java.lang.Long. So this consistently produced a Long
>>>> during select and when reading auto-incremented value via JDBC.
>>>>
>>>> Andrus
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>
>
>
Re: Problems with MySql id type with AUTO_INCREMENT
Posted by Tobias SCHOESSLER <To...@unvienna.org>.
I am a bit confused now ... so java.lang.Long PKs are known to not work at
all with cayenne 1.2 no matter which database is used?
I had the impression everything worked fine when using MySQL directly with
BIGINT, Long and database side AUTO_INCREMENT.
My last bug I ran into was only when I connected through the sequoia jdbc
driver / mysql jdbc driver chain when the test case broke again ...
Anyway I am flexible with the pk column types but because of this MySql
jdbc driver bug mentioned before
http://lists.mysql.com/java/6383
- returning meta data of type java.lang.Long for any AUTO_INCREMENT column
defined -
I thought I was forced to use some database type that consistently maps as
java.lang.Long for the PK to not have to deal with changing pk types on
creation and retrieval . That's why i tried INT UNSIGNED and BIGINT.
Is your advise still correct for this ?
Andrus Adamchik
<andrus@objectsty
le.org> To
cayenne-user@incubator.apache.org
Friday, 29 cc
September 2006
15:57 Subject
Re: Problems with MySql id type
with AUTO_INCREMENT
Please respond to
cayenne-user@incu
bator.apache.org
Tobias,
If you have flexibility redefining your columns, I suggest mapping a
PK as INTEGER until we implement Long PK support for real (http://
issues.apache.org/cayenne/browse/CAY-329). As far as I can tell in
the your latest case you are hitting the int pk limitation of PK
generator. This issue is pretty high on our priority list by the way,
so Long pks should become an option soon.
Andrus
On Sep 29, 2006, at 9:51 AM, Tobias SCHOESSLER wrote:
> Andrus, thanks a lot you for looking into this.
>
> That is quite a pile of bugs I am running into here. First this
> MySQL JDBC
> driver bug returning java.lang.Long for any auto-increment column,
> then
> cayenne treating 'INT UNSIGNED' as an Integer. Now issues with
> org.apache.cayenne.access.jdbc.ColumnDescriptor and SQLTemplate.
>
> To get this running for me I understand that I only have to pick
> the right
> datatype for my PKs so all the bugs are bypassed. Looking at
> http://dev.mysql.com/doc/refman/5.0/en/connector-j-reference-type-
> conversions.html
> I thought BIGINT should be unambigiously treated as a
> java.lang.Long for
> all bugs mentioned.
>
> Actually it worked, I tried setting the PKs to mysql type BIGINT
> and the
> test case mentioned below passes. So for the record this is a
> solution for
> using AUTO_INCREMENT PK generation with cayenne 1.2 and MySQL.
>
> But...
>
> If you recall my ultimate goal was to use a setup in which MySql is
> used in
> a Sequoia/CJDBC cluster - the reason I did not use AUTO_PK_SUPPORT
> as LOCK
> was not supported by Sequoia ...
>
> Connecting through the cjdbc/sequoia driver to the database above,
> again
> breaks the test case. Sequoia returns java.lang.Integer for the BIGINT
> column ... : -[
>
> I guess this is rather something to address in a sequoia forum or
> is there
> a chance you add a sequoia setup in your test cases?
>
> thanks
>
> Tobias
>
>
>
>
> Andrus Adamchik
> <andrus@objectsty
>
> le.org> To
> cayenne-
> user@incubator.apache.org
> Thursday,
> 28 cc
> September 2006
> 17:44
> Subject
> Re: Problems with MySql id type
> with AUTO_INCREMENT
> Please respond to
> cayenne-user@incu
> bator.apache.org
>
>
>
>
>
>
>
> Just got some time to test it, and the problem seems to be in
> org.apache.cayenne.access.jdbc.ColumnDescriptor constructor... It is
> getting confused by MySQL ResultSetMetaData returning JDBC type for
> such column as INTEGER.
>
> I created a new Jira issue with description of this problem:
>
> http://issues.apache.org/cayenne/browse/CAY-672
>
> I'll commit a fix to 3.0, as 1.2 users can have some code relying on
> the old behavior and we want to keep 1.2 stable.
>
> Andrus
>
>
> On Sep 26, 2006, at 7:11 AM, Tobias SCHOESSLER wrote:
>> Andrus,
>>
>> I am referring to http://issues.apache.org/cayenne/browse/CAY-639
>> and our
>> discussion below.
>>
>> I am using cayenne 1.2.1 now. I mapped all AUTO_INCREMENTED primary
>> keys of
>> sql type unsigned int as BIG_INT in cayenne.
>>
>> Cayenne correctly returns DataObjects with a primary key of type
>> Long when
>> using SelectQuery, when creating new objects or using getToXXX
>> navigation
>> to retrieve the object .
>>
>> But when I use SQLTemplate to retrieve the same DataObject cayenne
>> still
>> returns a pk of type Integer ...
>>
>> These are my test cases:
>>
>>
>> public void testDocumentPkViaSelectQuery() {
>> List<TldDocument> docList =
>> dataContext.performQuery(new
>> SelectQuery(TldDocument.class, null));
>> assertEquals(Long.class,
>> docList.get(0).getObjectId().getIdSnapshot().get
>> (TldDocument.DOCUMENT_UID_PK_COLUMN).getClass());
>>
>> }
>>
>> public void testDocumentPkViaSQLTemplate() {
>>
>> String sqlSelect = " select * ";
>> String sqlFrom = " from TLD_DOCUMENT doc ";
>>
>> SQLTemplate query = new SQLTemplate
>> (TldDocument.class,
>> sqlSelect + " " + sqlFrom);
>> List<TldDocument> docList =
>> dataContext.performQuery(query);
>>
>> assertEquals(Long.class,
>> docList.get(0).getObjectId().getIdSnapshot().get
>> (TldDocument.DOCUMENT_UID_PK_COLUMN).getClass());
>>
>> }
>>
>> testDocumentPkViaSelectQuery passes.
>>
>> testDocumentPkViaSQLTemplate fails.
>>
>> thanks, regards
>>
>> Tobias.
>>
>>
>>
>>
>>
>> Andrus Adamchik
>> <andrus@objectsty
>>
>> le.org> To
>> cayenne-
>> user@incubator.apache.org
>> Tuesday,
>> 29 cc
>> August 2006 15:35
>>
>> Subject
>> Re: Problems with MySql id
>> type
>> Please respond to with AUTO_INCREMENT
>> cayenne-user@incu
>> bator.apache.org
>>
>>
>>
>>
>>
>>
>>
>>
>> I'd appreciate that.
>>
>> Andrus
>>
>>
>> On Aug 29, 2006, at 5:31 PM, Tobias SCHOESSLER wrote:
>>
>>> ok, I got it. You want me to add a Jira entry for this? I never did
>>> this
>>> before ... : |
>>>
>>>
>>>
>>>
>>>
>>>
>>> Andrus Adamchik
>>> <andrus@objectsty
>>>
>>> le.org> To
>>> cayenne-
>>> user@incubator.apache.org
>>> Tuesday,
>>> 29 cc
>>> August 2006 15:19
>>>
>>> Subject
>>> Re: Problems with MySql id
>>> type
>>> Please respond to with AUTO_INCREMENT
>>> cayenne-user@incu
>>> bator.apache.org
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Aug 29, 2006, at 4:16 PM, Tobias SCHOESSLER wrote:
>>>
>>>> But still you are right there is a bug in mysql too. If the column
>>>> type is
>>>> INT and not INT UNSIGNED it should return java.lang.Integer but it
>>>> returns
>>>> java.lang.Long instead. This was my first observation.
>>>
>>> Still probably worth fixing the mapping to follow the docs.
>>>
>>>
>>>> but why does cayenne need BIGINT mapping set for the column to
>>>> retrieve it
>>>> as a java.lang.Long? I understand that this is unrelated to the bug
>>>> in the
>>>> mysql jdbc driver mentioned above.
>>>
>>> This is simply a workaround for the bug. BIGINT has a default JDBC
>>> mapping to java.lang.Long. So this consistently produced a Long
>>> during select and when reading auto-incremented value via JDBC.
>>>
>>> Andrus
>>>
>>>
>>>
>>
>>
>>
>>
>
>
>
>
Re: Problems with MySql id type with AUTO_INCREMENT
Posted by Andrus Adamchik <an...@objectstyle.org>.
Tobias,
If you have flexibility redefining your columns, I suggest mapping a
PK as INTEGER until we implement Long PK support for real (http://
issues.apache.org/cayenne/browse/CAY-329). As far as I can tell in
the your latest case you are hitting the int pk limitation of PK
generator. This issue is pretty high on our priority list by the way,
so Long pks should become an option soon.
Andrus
On Sep 29, 2006, at 9:51 AM, Tobias SCHOESSLER wrote:
> Andrus, thanks a lot you for looking into this.
>
> That is quite a pile of bugs I am running into here. First this
> MySQL JDBC
> driver bug returning java.lang.Long for any auto-increment column,
> then
> cayenne treating 'INT UNSIGNED' as an Integer. Now issues with
> org.apache.cayenne.access.jdbc.ColumnDescriptor and SQLTemplate.
>
> To get this running for me I understand that I only have to pick
> the right
> datatype for my PKs so all the bugs are bypassed. Looking at
> http://dev.mysql.com/doc/refman/5.0/en/connector-j-reference-type-
> conversions.html
> I thought BIGINT should be unambigiously treated as a
> java.lang.Long for
> all bugs mentioned.
>
> Actually it worked, I tried setting the PKs to mysql type BIGINT
> and the
> test case mentioned below passes. So for the record this is a
> solution for
> using AUTO_INCREMENT PK generation with cayenne 1.2 and MySQL.
>
> But...
>
> If you recall my ultimate goal was to use a setup in which MySql is
> used in
> a Sequoia/CJDBC cluster - the reason I did not use AUTO_PK_SUPPORT
> as LOCK
> was not supported by Sequoia ...
>
> Connecting through the cjdbc/sequoia driver to the database above,
> again
> breaks the test case. Sequoia returns java.lang.Integer for the BIGINT
> column ... : -[
>
> I guess this is rather something to address in a sequoia forum or
> is there
> a chance you add a sequoia setup in your test cases?
>
> thanks
>
> Tobias
>
>
>
>
> Andrus Adamchik
> <andrus@objectsty
>
> le.org> To
> cayenne-
> user@incubator.apache.org
> Thursday,
> 28 cc
> September 2006
> 17:44
> Subject
> Re: Problems with MySql id type
> with AUTO_INCREMENT
> Please respond to
> cayenne-user@incu
> bator.apache.org
>
>
>
>
>
>
>
> Just got some time to test it, and the problem seems to be in
> org.apache.cayenne.access.jdbc.ColumnDescriptor constructor... It is
> getting confused by MySQL ResultSetMetaData returning JDBC type for
> such column as INTEGER.
>
> I created a new Jira issue with description of this problem:
>
> http://issues.apache.org/cayenne/browse/CAY-672
>
> I'll commit a fix to 3.0, as 1.2 users can have some code relying on
> the old behavior and we want to keep 1.2 stable.
>
> Andrus
>
>
> On Sep 26, 2006, at 7:11 AM, Tobias SCHOESSLER wrote:
>> Andrus,
>>
>> I am referring to http://issues.apache.org/cayenne/browse/CAY-639
>> and our
>> discussion below.
>>
>> I am using cayenne 1.2.1 now. I mapped all AUTO_INCREMENTED primary
>> keys of
>> sql type unsigned int as BIG_INT in cayenne.
>>
>> Cayenne correctly returns DataObjects with a primary key of type
>> Long when
>> using SelectQuery, when creating new objects or using getToXXX
>> navigation
>> to retrieve the object .
>>
>> But when I use SQLTemplate to retrieve the same DataObject cayenne
>> still
>> returns a pk of type Integer ...
>>
>> These are my test cases:
>>
>>
>> public void testDocumentPkViaSelectQuery() {
>> List<TldDocument> docList =
>> dataContext.performQuery(new
>> SelectQuery(TldDocument.class, null));
>> assertEquals(Long.class,
>> docList.get(0).getObjectId().getIdSnapshot().get
>> (TldDocument.DOCUMENT_UID_PK_COLUMN).getClass());
>>
>> }
>>
>> public void testDocumentPkViaSQLTemplate() {
>>
>> String sqlSelect = " select * ";
>> String sqlFrom = " from TLD_DOCUMENT doc ";
>>
>> SQLTemplate query = new SQLTemplate
>> (TldDocument.class,
>> sqlSelect + " " + sqlFrom);
>> List<TldDocument> docList =
>> dataContext.performQuery(query);
>>
>> assertEquals(Long.class,
>> docList.get(0).getObjectId().getIdSnapshot().get
>> (TldDocument.DOCUMENT_UID_PK_COLUMN).getClass());
>>
>> }
>>
>> testDocumentPkViaSelectQuery passes.
>>
>> testDocumentPkViaSQLTemplate fails.
>>
>> thanks, regards
>>
>> Tobias.
>>
>>
>>
>>
>>
>> Andrus Adamchik
>> <andrus@objectsty
>>
>> le.org> To
>> cayenne-
>> user@incubator.apache.org
>> Tuesday,
>> 29 cc
>> August 2006 15:35
>>
>> Subject
>> Re: Problems with MySql id
>> type
>> Please respond to with AUTO_INCREMENT
>> cayenne-user@incu
>> bator.apache.org
>>
>>
>>
>>
>>
>>
>>
>>
>> I'd appreciate that.
>>
>> Andrus
>>
>>
>> On Aug 29, 2006, at 5:31 PM, Tobias SCHOESSLER wrote:
>>
>>> ok, I got it. You want me to add a Jira entry for this? I never did
>>> this
>>> before ... : |
>>>
>>>
>>>
>>>
>>>
>>>
>>> Andrus Adamchik
>>> <andrus@objectsty
>>>
>>> le.org> To
>>> cayenne-
>>> user@incubator.apache.org
>>> Tuesday,
>>> 29 cc
>>> August 2006 15:19
>>>
>>> Subject
>>> Re: Problems with MySql id
>>> type
>>> Please respond to with AUTO_INCREMENT
>>> cayenne-user@incu
>>> bator.apache.org
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Aug 29, 2006, at 4:16 PM, Tobias SCHOESSLER wrote:
>>>
>>>> But still you are right there is a bug in mysql too. If the column
>>>> type is
>>>> INT and not INT UNSIGNED it should return java.lang.Integer but it
>>>> returns
>>>> java.lang.Long instead. This was my first observation.
>>>
>>> Still probably worth fixing the mapping to follow the docs.
>>>
>>>
>>>> but why does cayenne need BIGINT mapping set for the column to
>>>> retrieve it
>>>> as a java.lang.Long? I understand that this is unrelated to the bug
>>>> in the
>>>> mysql jdbc driver mentioned above.
>>>
>>> This is simply a workaround for the bug. BIGINT has a default JDBC
>>> mapping to java.lang.Long. So this consistently produced a Long
>>> during select and when reading auto-incremented value via JDBC.
>>>
>>> Andrus
>>>
>>>
>>>
>>
>>
>>
>>
>
>
>
>
Re: Problems with MySql id type with AUTO_INCREMENT
Posted by Tobias SCHOESSLER <To...@unvienna.org>.
Andrus, thanks a lot you for looking into this.
That is quite a pile of bugs I am running into here. First this MySQL JDBC
driver bug returning java.lang.Long for any auto-increment column, then
cayenne treating 'INT UNSIGNED' as an Integer. Now issues with
org.apache.cayenne.access.jdbc.ColumnDescriptor and SQLTemplate.
To get this running for me I understand that I only have to pick the right
datatype for my PKs so all the bugs are bypassed. Looking at
http://dev.mysql.com/doc/refman/5.0/en/connector-j-reference-type-conversions.html
I thought BIGINT should be unambigiously treated as a java.lang.Long for
all bugs mentioned.
Actually it worked, I tried setting the PKs to mysql type BIGINT and the
test case mentioned below passes. So for the record this is a solution for
using AUTO_INCREMENT PK generation with cayenne 1.2 and MySQL.
But...
If you recall my ultimate goal was to use a setup in which MySql is used in
a Sequoia/CJDBC cluster - the reason I did not use AUTO_PK_SUPPORT as LOCK
was not supported by Sequoia ...
Connecting through the cjdbc/sequoia driver to the database above, again
breaks the test case. Sequoia returns java.lang.Integer for the BIGINT
column ... : -[
I guess this is rather something to address in a sequoia forum or is there
a chance you add a sequoia setup in your test cases?
thanks
Tobias
Andrus Adamchik
<andrus@objectsty
le.org> To
cayenne-user@incubator.apache.org
Thursday, 28 cc
September 2006
17:44 Subject
Re: Problems with MySql id type
with AUTO_INCREMENT
Please respond to
cayenne-user@incu
bator.apache.org
Just got some time to test it, and the problem seems to be in
org.apache.cayenne.access.jdbc.ColumnDescriptor constructor... It is
getting confused by MySQL ResultSetMetaData returning JDBC type for
such column as INTEGER.
I created a new Jira issue with description of this problem:
http://issues.apache.org/cayenne/browse/CAY-672
I'll commit a fix to 3.0, as 1.2 users can have some code relying on
the old behavior and we want to keep 1.2 stable.
Andrus
On Sep 26, 2006, at 7:11 AM, Tobias SCHOESSLER wrote:
> Andrus,
>
> I am referring to http://issues.apache.org/cayenne/browse/CAY-639
> and our
> discussion below.
>
> I am using cayenne 1.2.1 now. I mapped all AUTO_INCREMENTED primary
> keys of
> sql type unsigned int as BIG_INT in cayenne.
>
> Cayenne correctly returns DataObjects with a primary key of type
> Long when
> using SelectQuery, when creating new objects or using getToXXX
> navigation
> to retrieve the object .
>
> But when I use SQLTemplate to retrieve the same DataObject cayenne
> still
> returns a pk of type Integer ...
>
> These are my test cases:
>
>
> public void testDocumentPkViaSelectQuery() {
> List<TldDocument> docList =
> dataContext.performQuery(new
> SelectQuery(TldDocument.class, null));
> assertEquals(Long.class,
> docList.get(0).getObjectId().getIdSnapshot().get
> (TldDocument.DOCUMENT_UID_PK_COLUMN).getClass());
>
> }
>
> public void testDocumentPkViaSQLTemplate() {
>
> String sqlSelect = " select * ";
> String sqlFrom = " from TLD_DOCUMENT doc ";
>
> SQLTemplate query = new SQLTemplate
> (TldDocument.class,
> sqlSelect + " " + sqlFrom);
> List<TldDocument> docList =
> dataContext.performQuery(query);
>
> assertEquals(Long.class,
> docList.get(0).getObjectId().getIdSnapshot().get
> (TldDocument.DOCUMENT_UID_PK_COLUMN).getClass());
>
> }
>
> testDocumentPkViaSelectQuery passes.
>
> testDocumentPkViaSQLTemplate fails.
>
> thanks, regards
>
> Tobias.
>
>
>
>
>
> Andrus Adamchik
> <andrus@objectsty
>
> le.org> To
> cayenne-
> user@incubator.apache.org
> Tuesday,
> 29 cc
> August 2006 15:35
>
> Subject
> Re: Problems with MySql id type
> Please respond to with AUTO_INCREMENT
> cayenne-user@incu
> bator.apache.org
>
>
>
>
>
>
>
>
> I'd appreciate that.
>
> Andrus
>
>
> On Aug 29, 2006, at 5:31 PM, Tobias SCHOESSLER wrote:
>
>> ok, I got it. You want me to add a Jira entry for this? I never did
>> this
>> before ... : |
>>
>>
>>
>>
>>
>>
>> Andrus Adamchik
>> <andrus@objectsty
>>
>> le.org> To
>> cayenne-
>> user@incubator.apache.org
>> Tuesday,
>> 29 cc
>> August 2006 15:19
>>
>> Subject
>> Re: Problems with MySql id
>> type
>> Please respond to with AUTO_INCREMENT
>> cayenne-user@incu
>> bator.apache.org
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Aug 29, 2006, at 4:16 PM, Tobias SCHOESSLER wrote:
>>
>>> But still you are right there is a bug in mysql too. If the column
>>> type is
>>> INT and not INT UNSIGNED it should return java.lang.Integer but it
>>> returns
>>> java.lang.Long instead. This was my first observation.
>>
>> Still probably worth fixing the mapping to follow the docs.
>>
>>
>>> but why does cayenne need BIGINT mapping set for the column to
>>> retrieve it
>>> as a java.lang.Long? I understand that this is unrelated to the bug
>>> in the
>>> mysql jdbc driver mentioned above.
>>
>> This is simply a workaround for the bug. BIGINT has a default JDBC
>> mapping to java.lang.Long. So this consistently produced a Long
>> during select and when reading auto-incremented value via JDBC.
>>
>> Andrus
>>
>>
>>
>
>
>
>
Re: Problems with MySql id type with AUTO_INCREMENT
Posted by Andrus Adamchik <an...@objectstyle.org>.
Just got some time to test it, and the problem seems to be in
org.apache.cayenne.access.jdbc.ColumnDescriptor constructor... It is
getting confused by MySQL ResultSetMetaData returning JDBC type for
such column as INTEGER.
I created a new Jira issue with description of this problem:
http://issues.apache.org/cayenne/browse/CAY-672
I'll commit a fix to 3.0, as 1.2 users can have some code relying on
the old behavior and we want to keep 1.2 stable.
Andrus
On Sep 26, 2006, at 7:11 AM, Tobias SCHOESSLER wrote:
> Andrus,
>
> I am referring to http://issues.apache.org/cayenne/browse/CAY-639
> and our
> discussion below.
>
> I am using cayenne 1.2.1 now. I mapped all AUTO_INCREMENTED primary
> keys of
> sql type unsigned int as BIG_INT in cayenne.
>
> Cayenne correctly returns DataObjects with a primary key of type
> Long when
> using SelectQuery, when creating new objects or using getToXXX
> navigation
> to retrieve the object .
>
> But when I use SQLTemplate to retrieve the same DataObject cayenne
> still
> returns a pk of type Integer ...
>
> These are my test cases:
>
>
> public void testDocumentPkViaSelectQuery() {
> List<TldDocument> docList =
> dataContext.performQuery(new
> SelectQuery(TldDocument.class, null));
> assertEquals(Long.class,
> docList.get(0).getObjectId().getIdSnapshot().get
> (TldDocument.DOCUMENT_UID_PK_COLUMN).getClass());
>
> }
>
> public void testDocumentPkViaSQLTemplate() {
>
> String sqlSelect = " select * ";
> String sqlFrom = " from TLD_DOCUMENT doc ";
>
> SQLTemplate query = new SQLTemplate
> (TldDocument.class,
> sqlSelect + " " + sqlFrom);
> List<TldDocument> docList =
> dataContext.performQuery(query);
>
> assertEquals(Long.class,
> docList.get(0).getObjectId().getIdSnapshot().get
> (TldDocument.DOCUMENT_UID_PK_COLUMN).getClass());
>
> }
>
> testDocumentPkViaSelectQuery passes.
>
> testDocumentPkViaSQLTemplate fails.
>
> thanks, regards
>
> Tobias.
>
>
>
>
>
> Andrus Adamchik
> <andrus@objectsty
>
> le.org> To
> cayenne-
> user@incubator.apache.org
> Tuesday,
> 29 cc
> August 2006 15:35
>
> Subject
> Re: Problems with MySql id type
> Please respond to with AUTO_INCREMENT
> cayenne-user@incu
> bator.apache.org
>
>
>
>
>
>
>
>
> I'd appreciate that.
>
> Andrus
>
>
> On Aug 29, 2006, at 5:31 PM, Tobias SCHOESSLER wrote:
>
>> ok, I got it. You want me to add a Jira entry for this? I never did
>> this
>> before ... : |
>>
>>
>>
>>
>>
>>
>> Andrus Adamchik
>> <andrus@objectsty
>>
>> le.org> To
>> cayenne-
>> user@incubator.apache.org
>> Tuesday,
>> 29 cc
>> August 2006 15:19
>>
>> Subject
>> Re: Problems with MySql id
>> type
>> Please respond to with AUTO_INCREMENT
>> cayenne-user@incu
>> bator.apache.org
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Aug 29, 2006, at 4:16 PM, Tobias SCHOESSLER wrote:
>>
>>> But still you are right there is a bug in mysql too. If the column
>>> type is
>>> INT and not INT UNSIGNED it should return java.lang.Integer but it
>>> returns
>>> java.lang.Long instead. This was my first observation.
>>
>> Still probably worth fixing the mapping to follow the docs.
>>
>>
>>> but why does cayenne need BIGINT mapping set for the column to
>>> retrieve it
>>> as a java.lang.Long? I understand that this is unrelated to the bug
>>> in the
>>> mysql jdbc driver mentioned above.
>>
>> This is simply a workaround for the bug. BIGINT has a default JDBC
>> mapping to java.lang.Long. So this consistently produced a Long
>> during select and when reading auto-incremented value via JDBC.
>>
>> Andrus
>>
>>
>>
>
>
>
>
Re: Problems with MySql id type with AUTO_INCREMENT
Posted by Tobias SCHOESSLER <To...@unvienna.org>.
Andrus,
I am referring to http://issues.apache.org/cayenne/browse/CAY-639 and our
discussion below.
I am using cayenne 1.2.1 now. I mapped all AUTO_INCREMENTED primary keys of
sql type unsigned int as BIG_INT in cayenne.
Cayenne correctly returns DataObjects with a primary key of type Long when
using SelectQuery, when creating new objects or using getToXXX navigation
to retrieve the object .
But when I use SQLTemplate to retrieve the same DataObject cayenne still
returns a pk of type Integer ...
These are my test cases:
public void testDocumentPkViaSelectQuery() {
List<TldDocument> docList = dataContext.performQuery(new
SelectQuery(TldDocument.class, null));
assertEquals(Long.class,
docList.get(0).getObjectId().getIdSnapshot().get(TldDocument.DOCUMENT_UID_PK_COLUMN).getClass());
}
public void testDocumentPkViaSQLTemplate() {
String sqlSelect = " select * ";
String sqlFrom = " from TLD_DOCUMENT doc ";
SQLTemplate query = new SQLTemplate(TldDocument.class,
sqlSelect + " " + sqlFrom);
List<TldDocument> docList =
dataContext.performQuery(query);
assertEquals(Long.class,
docList.get(0).getObjectId().getIdSnapshot().get(TldDocument.DOCUMENT_UID_PK_COLUMN).getClass());
}
testDocumentPkViaSelectQuery passes.
testDocumentPkViaSQLTemplate fails.
thanks, regards
Tobias.
Andrus Adamchik
<andrus@objectsty
le.org> To
cayenne-user@incubator.apache.org
Tuesday, 29 cc
August 2006 15:35
Subject
Re: Problems with MySql id type
Please respond to with AUTO_INCREMENT
cayenne-user@incu
bator.apache.org
I'd appreciate that.
Andrus
On Aug 29, 2006, at 5:31 PM, Tobias SCHOESSLER wrote:
> ok, I got it. You want me to add a Jira entry for this? I never did
> this
> before ... : |
>
>
>
>
>
>
> Andrus Adamchik
> <andrus@objectsty
>
> le.org> To
> cayenne-
> user@incubator.apache.org
> Tuesday,
> 29 cc
> August 2006 15:19
>
> Subject
> Re: Problems with MySql id type
> Please respond to with AUTO_INCREMENT
> cayenne-user@incu
> bator.apache.org
>
>
>
>
>
>
>
>
>
> On Aug 29, 2006, at 4:16 PM, Tobias SCHOESSLER wrote:
>
>> But still you are right there is a bug in mysql too. If the column
>> type is
>> INT and not INT UNSIGNED it should return java.lang.Integer but it
>> returns
>> java.lang.Long instead. This was my first observation.
>
> Still probably worth fixing the mapping to follow the docs.
>
>
>> but why does cayenne need BIGINT mapping set for the column to
>> retrieve it
>> as a java.lang.Long? I understand that this is unrelated to the bug
>> in the
>> mysql jdbc driver mentioned above.
>
> This is simply a workaround for the bug. BIGINT has a default JDBC
> mapping to java.lang.Long. So this consistently produced a Long
> during select and when reading auto-incremented value via JDBC.
>
> Andrus
>
>
>
Re: Problems with MySql id type with AUTO_INCREMENT
Posted by Andrus Adamchik <an...@objectstyle.org>.
I'd appreciate that.
Andrus
On Aug 29, 2006, at 5:31 PM, Tobias SCHOESSLER wrote:
> ok, I got it. You want me to add a Jira entry for this? I never did
> this
> before ... : |
>
>
>
>
>
>
> Andrus Adamchik
> <andrus@objectsty
>
> le.org> To
> cayenne-
> user@incubator.apache.org
> Tuesday,
> 29 cc
> August 2006 15:19
>
> Subject
> Re: Problems with MySql id type
> Please respond to with AUTO_INCREMENT
> cayenne-user@incu
> bator.apache.org
>
>
>
>
>
>
>
>
>
> On Aug 29, 2006, at 4:16 PM, Tobias SCHOESSLER wrote:
>
>> But still you are right there is a bug in mysql too. If the column
>> type is
>> INT and not INT UNSIGNED it should return java.lang.Integer but it
>> returns
>> java.lang.Long instead. This was my first observation.
>
> Still probably worth fixing the mapping to follow the docs.
>
>
>> but why does cayenne need BIGINT mapping set for the column to
>> retrieve it
>> as a java.lang.Long? I understand that this is unrelated to the bug
>> in the
>> mysql jdbc driver mentioned above.
>
> This is simply a workaround for the bug. BIGINT has a default JDBC
> mapping to java.lang.Long. So this consistently produced a Long
> during select and when reading auto-incremented value via JDBC.
>
> Andrus
>
>
>
Re: Problems with MySql id type with AUTO_INCREMENT
Posted by Tobias SCHOESSLER <To...@unvienna.org>.
ok, I got it. You want me to add a Jira entry for this? I never did this
before ... : |
Andrus Adamchik
<andrus@objectsty
le.org> To
cayenne-user@incubator.apache.org
Tuesday, 29 cc
August 2006 15:19
Subject
Re: Problems with MySql id type
Please respond to with AUTO_INCREMENT
cayenne-user@incu
bator.apache.org
On Aug 29, 2006, at 4:16 PM, Tobias SCHOESSLER wrote:
> But still you are right there is a bug in mysql too. If the column
> type is
> INT and not INT UNSIGNED it should return java.lang.Integer but it
> returns
> java.lang.Long instead. This was my first observation.
Still probably worth fixing the mapping to follow the docs.
> but why does cayenne need BIGINT mapping set for the column to
> retrieve it
> as a java.lang.Long? I understand that this is unrelated to the bug
> in the
> mysql jdbc driver mentioned above.
This is simply a workaround for the bug. BIGINT has a default JDBC
mapping to java.lang.Long. So this consistently produced a Long
during select and when reading auto-incremented value via JDBC.
Andrus
Re: Problems with MySql id type with AUTO_INCREMENT
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Aug 29, 2006, at 4:16 PM, Tobias SCHOESSLER wrote:
> But still you are right there is a bug in mysql too. If the column
> type is
> INT and not INT UNSIGNED it should return java.lang.Integer but it
> returns
> java.lang.Long instead. This was my first observation.
Still probably worth fixing the mapping to follow the docs.
> but why does cayenne need BIGINT mapping set for the column to
> retrieve it
> as a java.lang.Long? I understand that this is unrelated to the bug
> in the
> mysql jdbc driver mentioned above.
This is simply a workaround for the bug. BIGINT has a default JDBC
mapping to java.lang.Long. So this consistently produced a Long
during select and when reading auto-incremented value via JDBC.
Andrus
Re: Problems with MySql id type with AUTO_INCREMENT
Posted by Tobias SCHOESSLER <To...@unvienna.org>.
But still you are right there is a bug in mysql too. If the column type is
INT and not INT UNSIGNED it should return java.lang.Integer but it returns
java.lang.Long instead. This was my first observation.
http://lists.mysql.com/java/6383
this is from jconnector 3.0.8 but I don't see it fixed in the 3.1.13
release notes.
So this is the reason why I got a class cast exception for the PK in the
first place. Then I changed the mysql datatype to INT UNSIGNED.
but why does cayenne need BIGINT mapping set for the column to retrieve it
as a java.lang.Long? I understand that this is unrelated to the bug in the
mysql jdbc driver mentioned above.
Andrus Adamchik
<andrus@objectsty
le.org> To
cayenne-user@incubator.apache.org
Tuesday, 29 cc
August 2006 13:45
Subject
Re: Problems with MySql id type
Please respond to with AUTO_INCREMENT
cayenne-user@incu
bator.apache.org
You are right: "INTEGER [UNSIGNED] [...] java.lang.Integer, if
UNSIGNED java.lang.Long". Who would've thought! :-)
I'd appreciate a Jira issue so that we don't forget about it.
Andrus
On Aug 29, 2006, at 3:40 PM, Tobias SCHOESSLER wrote:
> For the driver I use mysql-connector-java-3.1.13-bin.jar
>
> here
>
> http://dev.mysql.com/doc/refman/5.0/en/connector-j-reference-type-
> conversions.html
>
> it reads that INT UNSIGNED should map to java.lang.Long. This is
> fine I
> think and it is correct right after creation of the object.
>
> But why is the type of the column java.lang.Integer when I retrieve
> the
> value later via cayenne? Isn't the bug rather to search there?
>
>
>
>
>
>
> Andrus Adamchik
> <andrus@objectsty
>
> le.org> To
> cayenne-
> user@incubator.apache.org
> Tuesday,
> 29 cc
> August 2006 13:27
>
> Subject
> Re: Problems with MySql id type
> Please respond to with AUTO_INCREMENT
> cayenne-user@incu
> bator.apache.org
>
>
>
>
>
>
>
>
> I don't think that globally changing INT to be mapped to JDBC BIGINT
> is a good idea (although this can be done by editing org/objectstyle/
> cayenne/dba/mysql/types.xml). What is confusing to me is why the
> generated key is java.lang.Long for the INTEGER column. Could be a
> MySQL driver bug???
>
> Andrus
>
>
> On Aug 29, 2006, at 3:15 PM, Tobias SCHOESSLER wrote:
>
>> it was mapped as
>>
>> <db-attribute ... type="INTEGER" length="10"/>
>>
>> I changed the type to BIGINT and now the PK is always a Long. Great,
>> thanks. This was hard to guess.
>>
>> Is the jdbc type mapping messed up for the MySQL Adapter?
>>
>> When I reverse engineer the db from scratch
>>
>> INT UNSIGNED is mapped as <db-attribute ... type="INTEGER"
>> length="10"/>
>>
>> INT is mapped as <db-attribute ... type="INTEGER" length="11"/>
>>
>> Could you give me a hint where to change this mapping so I do not
>> have to
>> set it to BIGINT manually?
>>
>> thank you
>>
>> Tobias
>>
>>
>>
>>
>>
>> Andrus Adamchik
>> <andrus@objectsty
>>
>> le.org> To
>> cayenne-
>> user@incubator.apache.org
>> Tuesday,
>> 29 cc
>> August 2006 11:00
>>
>> Subject
>> Re: Problems with MySql id
>> type
>> Please respond to with AUTO_INCREMENT
>> cayenne-user@incu
>> bator.apache.org
>>
>>
>>
>>
>>
>>
>>
>>
>> How is the column mapped in the Modeler? Have you tried mapping it as
>> BIGINT?
>>
>> Andrus
>>
>>
>>
>> On Aug 28, 2006, at 1:22 PM, Tobias SCHOESSLER wrote:
>>
>>>
>>> I use cayenne 1.2, MySql. AUTO_INCREMENT ids
>>>
>>> the type of the id field in the mysql schema is set to
>>>
>>> INT NOT NULL AUTO_INCREMENT UNIQUE
>>>
>>> I create an object of this table with cayenne and commit. I see the
>>> row
>>> inserted ok. When accessing the Id of the object via
>>>
>>> getObjectId().getIdSnapshot().get(this.FOLDER_UID_PK_COLUMN)
>>>
>>> in the same DataContext the type of the Object retruned is a Long.
>>> (Though
>>> I would have expected it to be an Integer from the MySql jdbc
>>> documentation)
>>>
>>> When I use a fresh DataContext and retrieve the same row the id
>>> object
>>> returned by
>>>
>>> getObjectId().getIdSnapshot().get(this.FOLDER_UID_PK_COLUMN)
>>>
>>> seems to be an Integer ?
>>>
>>>
>>>
>>> I tried to set the type to
>>>
>>> INT UNSIGNED NOT NULL AUTO_INCREMENT UNIQUE
>>>
>>> which is supposed to be of Long type from the jdbc type
>>> documentation of
>>> MySql.
>>>
>>> to force the id object always to be a Long but cayenne still
>>> returns an
>>> Integer when reading from the db.
>>>
>>> any ideas?
>>>
>>> thanks
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>
>
>
Re: Problems with MySql id type with AUTO_INCREMENT
Posted by Andrus Adamchik <an...@objectstyle.org>.
You are right: "INTEGER [UNSIGNED] [...] java.lang.Integer, if
UNSIGNED java.lang.Long". Who would've thought! :-)
I'd appreciate a Jira issue so that we don't forget about it.
Andrus
On Aug 29, 2006, at 3:40 PM, Tobias SCHOESSLER wrote:
> For the driver I use mysql-connector-java-3.1.13-bin.jar
>
> here
>
> http://dev.mysql.com/doc/refman/5.0/en/connector-j-reference-type-
> conversions.html
>
> it reads that INT UNSIGNED should map to java.lang.Long. This is
> fine I
> think and it is correct right after creation of the object.
>
> But why is the type of the column java.lang.Integer when I retrieve
> the
> value later via cayenne? Isn't the bug rather to search there?
>
>
>
>
>
>
> Andrus Adamchik
> <andrus@objectsty
>
> le.org> To
> cayenne-
> user@incubator.apache.org
> Tuesday,
> 29 cc
> August 2006 13:27
>
> Subject
> Re: Problems with MySql id type
> Please respond to with AUTO_INCREMENT
> cayenne-user@incu
> bator.apache.org
>
>
>
>
>
>
>
>
> I don't think that globally changing INT to be mapped to JDBC BIGINT
> is a good idea (although this can be done by editing org/objectstyle/
> cayenne/dba/mysql/types.xml). What is confusing to me is why the
> generated key is java.lang.Long for the INTEGER column. Could be a
> MySQL driver bug???
>
> Andrus
>
>
> On Aug 29, 2006, at 3:15 PM, Tobias SCHOESSLER wrote:
>
>> it was mapped as
>>
>> <db-attribute ... type="INTEGER" length="10"/>
>>
>> I changed the type to BIGINT and now the PK is always a Long. Great,
>> thanks. This was hard to guess.
>>
>> Is the jdbc type mapping messed up for the MySQL Adapter?
>>
>> When I reverse engineer the db from scratch
>>
>> INT UNSIGNED is mapped as <db-attribute ... type="INTEGER"
>> length="10"/>
>>
>> INT is mapped as <db-attribute ... type="INTEGER" length="11"/>
>>
>> Could you give me a hint where to change this mapping so I do not
>> have to
>> set it to BIGINT manually?
>>
>> thank you
>>
>> Tobias
>>
>>
>>
>>
>>
>> Andrus Adamchik
>> <andrus@objectsty
>>
>> le.org> To
>> cayenne-
>> user@incubator.apache.org
>> Tuesday,
>> 29 cc
>> August 2006 11:00
>>
>> Subject
>> Re: Problems with MySql id
>> type
>> Please respond to with AUTO_INCREMENT
>> cayenne-user@incu
>> bator.apache.org
>>
>>
>>
>>
>>
>>
>>
>>
>> How is the column mapped in the Modeler? Have you tried mapping it as
>> BIGINT?
>>
>> Andrus
>>
>>
>>
>> On Aug 28, 2006, at 1:22 PM, Tobias SCHOESSLER wrote:
>>
>>>
>>> I use cayenne 1.2, MySql. AUTO_INCREMENT ids
>>>
>>> the type of the id field in the mysql schema is set to
>>>
>>> INT NOT NULL AUTO_INCREMENT UNIQUE
>>>
>>> I create an object of this table with cayenne and commit. I see the
>>> row
>>> inserted ok. When accessing the Id of the object via
>>>
>>> getObjectId().getIdSnapshot().get(this.FOLDER_UID_PK_COLUMN)
>>>
>>> in the same DataContext the type of the Object retruned is a Long.
>>> (Though
>>> I would have expected it to be an Integer from the MySql jdbc
>>> documentation)
>>>
>>> When I use a fresh DataContext and retrieve the same row the id
>>> object
>>> returned by
>>>
>>> getObjectId().getIdSnapshot().get(this.FOLDER_UID_PK_COLUMN)
>>>
>>> seems to be an Integer ?
>>>
>>>
>>>
>>> I tried to set the type to
>>>
>>> INT UNSIGNED NOT NULL AUTO_INCREMENT UNIQUE
>>>
>>> which is supposed to be of Long type from the jdbc type
>>> documentation of
>>> MySql.
>>>
>>> to force the id object always to be a Long but cayenne still
>>> returns an
>>> Integer when reading from the db.
>>>
>>> any ideas?
>>>
>>> thanks
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>
>
>
Re: Problems with MySql id type with AUTO_INCREMENT
Posted by Tobias SCHOESSLER <To...@unvienna.org>.
For the driver I use mysql-connector-java-3.1.13-bin.jar
here
http://dev.mysql.com/doc/refman/5.0/en/connector-j-reference-type-conversions.html
it reads that INT UNSIGNED should map to java.lang.Long. This is fine I
think and it is correct right after creation of the object.
But why is the type of the column java.lang.Integer when I retrieve the
value later via cayenne? Isn't the bug rather to search there?
Andrus Adamchik
<andrus@objectsty
le.org> To
cayenne-user@incubator.apache.org
Tuesday, 29 cc
August 2006 13:27
Subject
Re: Problems with MySql id type
Please respond to with AUTO_INCREMENT
cayenne-user@incu
bator.apache.org
I don't think that globally changing INT to be mapped to JDBC BIGINT
is a good idea (although this can be done by editing org/objectstyle/
cayenne/dba/mysql/types.xml). What is confusing to me is why the
generated key is java.lang.Long for the INTEGER column. Could be a
MySQL driver bug???
Andrus
On Aug 29, 2006, at 3:15 PM, Tobias SCHOESSLER wrote:
> it was mapped as
>
> <db-attribute ... type="INTEGER" length="10"/>
>
> I changed the type to BIGINT and now the PK is always a Long. Great,
> thanks. This was hard to guess.
>
> Is the jdbc type mapping messed up for the MySQL Adapter?
>
> When I reverse engineer the db from scratch
>
> INT UNSIGNED is mapped as <db-attribute ... type="INTEGER"
> length="10"/>
>
> INT is mapped as <db-attribute ... type="INTEGER" length="11"/>
>
> Could you give me a hint where to change this mapping so I do not
> have to
> set it to BIGINT manually?
>
> thank you
>
> Tobias
>
>
>
>
>
> Andrus Adamchik
> <andrus@objectsty
>
> le.org> To
> cayenne-
> user@incubator.apache.org
> Tuesday,
> 29 cc
> August 2006 11:00
>
> Subject
> Re: Problems with MySql id type
> Please respond to with AUTO_INCREMENT
> cayenne-user@incu
> bator.apache.org
>
>
>
>
>
>
>
>
> How is the column mapped in the Modeler? Have you tried mapping it as
> BIGINT?
>
> Andrus
>
>
>
> On Aug 28, 2006, at 1:22 PM, Tobias SCHOESSLER wrote:
>
>>
>> I use cayenne 1.2, MySql. AUTO_INCREMENT ids
>>
>> the type of the id field in the mysql schema is set to
>>
>> INT NOT NULL AUTO_INCREMENT UNIQUE
>>
>> I create an object of this table with cayenne and commit. I see the
>> row
>> inserted ok. When accessing the Id of the object via
>>
>> getObjectId().getIdSnapshot().get(this.FOLDER_UID_PK_COLUMN)
>>
>> in the same DataContext the type of the Object retruned is a Long.
>> (Though
>> I would have expected it to be an Integer from the MySql jdbc
>> documentation)
>>
>> When I use a fresh DataContext and retrieve the same row the id
>> object
>> returned by
>>
>> getObjectId().getIdSnapshot().get(this.FOLDER_UID_PK_COLUMN)
>>
>> seems to be an Integer ?
>>
>>
>>
>> I tried to set the type to
>>
>> INT UNSIGNED NOT NULL AUTO_INCREMENT UNIQUE
>>
>> which is supposed to be of Long type from the jdbc type
>> documentation of
>> MySql.
>>
>> to force the id object always to be a Long but cayenne still
>> returns an
>> Integer when reading from the db.
>>
>> any ideas?
>>
>> thanks
>>
>>
>>
>>
>
>
>
>
Re: Problems with MySql id type with AUTO_INCREMENT
Posted by Andrus Adamchik <an...@objectstyle.org>.
I don't think that globally changing INT to be mapped to JDBC BIGINT
is a good idea (although this can be done by editing org/objectstyle/
cayenne/dba/mysql/types.xml). What is confusing to me is why the
generated key is java.lang.Long for the INTEGER column. Could be a
MySQL driver bug???
Andrus
On Aug 29, 2006, at 3:15 PM, Tobias SCHOESSLER wrote:
> it was mapped as
>
> <db-attribute ... type="INTEGER" length="10"/>
>
> I changed the type to BIGINT and now the PK is always a Long. Great,
> thanks. This was hard to guess.
>
> Is the jdbc type mapping messed up for the MySQL Adapter?
>
> When I reverse engineer the db from scratch
>
> INT UNSIGNED is mapped as <db-attribute ... type="INTEGER"
> length="10"/>
>
> INT is mapped as <db-attribute ... type="INTEGER" length="11"/>
>
> Could you give me a hint where to change this mapping so I do not
> have to
> set it to BIGINT manually?
>
> thank you
>
> Tobias
>
>
>
>
>
> Andrus Adamchik
> <andrus@objectsty
>
> le.org> To
> cayenne-
> user@incubator.apache.org
> Tuesday,
> 29 cc
> August 2006 11:00
>
> Subject
> Re: Problems with MySql id type
> Please respond to with AUTO_INCREMENT
> cayenne-user@incu
> bator.apache.org
>
>
>
>
>
>
>
>
> How is the column mapped in the Modeler? Have you tried mapping it as
> BIGINT?
>
> Andrus
>
>
>
> On Aug 28, 2006, at 1:22 PM, Tobias SCHOESSLER wrote:
>
>>
>> I use cayenne 1.2, MySql. AUTO_INCREMENT ids
>>
>> the type of the id field in the mysql schema is set to
>>
>> INT NOT NULL AUTO_INCREMENT UNIQUE
>>
>> I create an object of this table with cayenne and commit. I see the
>> row
>> inserted ok. When accessing the Id of the object via
>>
>> getObjectId().getIdSnapshot().get(this.FOLDER_UID_PK_COLUMN)
>>
>> in the same DataContext the type of the Object retruned is a Long.
>> (Though
>> I would have expected it to be an Integer from the MySql jdbc
>> documentation)
>>
>> When I use a fresh DataContext and retrieve the same row the id
>> object
>> returned by
>>
>> getObjectId().getIdSnapshot().get(this.FOLDER_UID_PK_COLUMN)
>>
>> seems to be an Integer ?
>>
>>
>>
>> I tried to set the type to
>>
>> INT UNSIGNED NOT NULL AUTO_INCREMENT UNIQUE
>>
>> which is supposed to be of Long type from the jdbc type
>> documentation of
>> MySql.
>>
>> to force the id object always to be a Long but cayenne still
>> returns an
>> Integer when reading from the db.
>>
>> any ideas?
>>
>> thanks
>>
>>
>>
>>
>
>
>
>
Re: Problems with MySql id type with AUTO_INCREMENT
Posted by Tobias SCHOESSLER <To...@unvienna.org>.
it was mapped as
<db-attribute ... type="INTEGER" length="10"/>
I changed the type to BIGINT and now the PK is always a Long. Great,
thanks. This was hard to guess.
Is the jdbc type mapping messed up for the MySQL Adapter?
When I reverse engineer the db from scratch
INT UNSIGNED is mapped as <db-attribute ... type="INTEGER" length="10"/>
INT is mapped as <db-attribute ... type="INTEGER" length="11"/>
Could you give me a hint where to change this mapping so I do not have to
set it to BIGINT manually?
thank you
Tobias
Andrus Adamchik
<andrus@objectsty
le.org> To
cayenne-user@incubator.apache.org
Tuesday, 29 cc
August 2006 11:00
Subject
Re: Problems with MySql id type
Please respond to with AUTO_INCREMENT
cayenne-user@incu
bator.apache.org
How is the column mapped in the Modeler? Have you tried mapping it as
BIGINT?
Andrus
On Aug 28, 2006, at 1:22 PM, Tobias SCHOESSLER wrote:
>
> I use cayenne 1.2, MySql. AUTO_INCREMENT ids
>
> the type of the id field in the mysql schema is set to
>
> INT NOT NULL AUTO_INCREMENT UNIQUE
>
> I create an object of this table with cayenne and commit. I see the
> row
> inserted ok. When accessing the Id of the object via
>
> getObjectId().getIdSnapshot().get(this.FOLDER_UID_PK_COLUMN)
>
> in the same DataContext the type of the Object retruned is a Long.
> (Though
> I would have expected it to be an Integer from the MySql jdbc
> documentation)
>
> When I use a fresh DataContext and retrieve the same row the id object
> returned by
>
> getObjectId().getIdSnapshot().get(this.FOLDER_UID_PK_COLUMN)
>
> seems to be an Integer ?
>
>
>
> I tried to set the type to
>
> INT UNSIGNED NOT NULL AUTO_INCREMENT UNIQUE
>
> which is supposed to be of Long type from the jdbc type
> documentation of
> MySql.
>
> to force the id object always to be a Long but cayenne still
> returns an
> Integer when reading from the db.
>
> any ideas?
>
> thanks
>
>
>
>
Re: Problems with MySql id type with AUTO_INCREMENT
Posted by Andrus Adamchik <an...@objectstyle.org>.
How is the column mapped in the Modeler? Have you tried mapping it as
BIGINT?
Andrus
On Aug 28, 2006, at 1:22 PM, Tobias SCHOESSLER wrote:
>
> I use cayenne 1.2, MySql. AUTO_INCREMENT ids
>
> the type of the id field in the mysql schema is set to
>
> INT NOT NULL AUTO_INCREMENT UNIQUE
>
> I create an object of this table with cayenne and commit. I see the
> row
> inserted ok. When accessing the Id of the object via
>
> getObjectId().getIdSnapshot().get(this.FOLDER_UID_PK_COLUMN)
>
> in the same DataContext the type of the Object retruned is a Long.
> (Though
> I would have expected it to be an Integer from the MySql jdbc
> documentation)
>
> When I use a fresh DataContext and retrieve the same row the id object
> returned by
>
> getObjectId().getIdSnapshot().get(this.FOLDER_UID_PK_COLUMN)
>
> seems to be an Integer ?
>
>
>
> I tried to set the type to
>
> INT UNSIGNED NOT NULL AUTO_INCREMENT UNIQUE
>
> which is supposed to be of Long type from the jdbc type
> documentation of
> MySql.
>
> to force the id object always to be a Long but cayenne still
> returns an
> Integer when reading from the db.
>
> any ideas?
>
> thanks
>
>
>
>