important discovery, studies the one afternoon

Found that if the call dao an insert operation, return on the primary key in the assignment to DO object id attributes, but the id of the object is for Integer types, the return value is forcibly assignment into Long, and the id is of type Integer gives actually became a Long value, is terrible, can't make any for the value of the operation,
Otherwise will be submitted to the Java. Lang. Long always be cast to Java. Lang, Integer, and in the mapping file, will return to the insert statement on the id mapping in the object, the other members of the type Integer, also will not be strong, when I want to insert now to obtain primary key id then assignment on the id attribute of object, but of type Integer, may god grant called

CodePudding user response:

What database, and what is the primary key access, stick your mapping file

CodePudding user response:

The mysql database when no class mapping this is inserted into the keyProperty separate mapping to the id field

CodePudding user response:

These graphs

CodePudding user response:

UseGenerateKeys is to use mysql on the primary key, return is Long, if you want to change the type, you can use custom primary keys, like oracle, can define resultType

CodePudding user response:

Don't agree with this point of view, I has already demonstrated that if useGenerateKeys mapping field name is not id, type Integer, as mapping can succeed, and mapping out the value is an Integer, not to be strong to Long

CodePudding user response:

See your BOssDo about id set inside, the get method, the parameter is what type, and your figure inside an id value is 1, how to figure 2 into long 18 in it? Feeling which part you write wrong

CodePudding user response:

Feeling problems out on your BossDo entity class, complete code stick out and have a look

CodePudding user response:

The database id of the type and length is how much, if there is any more than in Java Integer range

CodePudding user response:

Figure 1 is 1, it is my first sentence manual assignment 1, prove that he is an Integer, originally for the sake of contrast, and behind set and get no problem, check the countless times, otherwise figure 1 also does not show is an Integer

CodePudding user response:

references 9 f qq_36093850 response:

figure 1 is 1, is my first sentence manual assignment 1, prove that he is an Integer, originally for the sake of contrast, and behind set and get no problem, check the countless times, otherwise figure 1 also does not show is an Integer

set is no problem, and figure 1 also no problem, but why in figure 2 turned 18, you manually change? Also, your BossDo entity class have to write inside the constructor

CodePudding user response:

So, you see a breakpoint, after performing the insert statement, mybatis can not return to the current on the id to a field, I mapped to the id, as a result of the strong to Long

CodePudding user response:

11

reference qq_36093850 response:

so ah, you see a breakpoint, after performing the insert statement, mybatis can not return to the current on the id to a field, I mapped to the id, the results strongly into the Long

database design of the table on the id, you look at what the type of the type can be Long

CodePudding user response:

Data table is normal

CodePudding user response:

This really is a bug of mybatis I want to say is, a total of 3

1. & lt; Insert> Statements, keyProperty value assignment of field name if it's id, so if this id is an Integer type, as Long as it's not Long, will be equivalent to Long, because of the type mismatch, id field use would be an error

2. The keyProperty value assignment of field name is not Long, so what is the field name type, is what type of assignment, to return to normal

CodePudding user response:

Turn the type stronger

CodePudding user response:

The select LAST_INSERT_ID ();


In this way,

CodePudding user response:

Fields have set the UNSIGNED
Is a signed or unsigned integer
Don't know if you this store is not the same as the scope and the Integer

CodePudding user response:

Absolutely not data table definition of the problem, because as long as I to replace mapping field name with the rest of the don't call id, then returns an Integer that field is an Integer

CodePudding user response:

Is strong turn as a result, the id field has been scrapped, whether get or set, will be submitted to the type does not match the problem, because itself has been turned, and is a Long Integer, small turn big, not by the transformation of the compiler

CodePudding user response:

Check whether there is: an INTEGER

jdbcType="INTEGER" property="XXXXX"/& gt;
.

CodePudding user response:

With & lt; ResultMap> No relationship, that is the query result mapping, this is & lt; Insert> Statements, return on the id of the keyProperty mapping

CodePudding user response:

I deeply doubt your XML isn't write the Long type ResultMap?

CodePudding user response:

, this is & lt; Insert> Statements, return on the id of the keyProperty mapping, my & lt; ResultMap> No mapping my id value

CodePudding user response:

Behind the keyProperty="id" you add a try resultType="int"

CodePudding user response:

There is no this article attribute tried mybatis...

CodePudding user response:

Table id types such as bigint, a try, if so no problem it might be like the 4th floor, when the growth of the generated long type of

CodePudding user response:

Everybody is good, one day after the debugging, almost already ascertained, is mybatis problem, temporarily unable to define whether a bug

CodePudding user response:

Because I am a subclass the POJO, inherited the parent class, specifies the generic, in this paper, my id is in the parent class, so, when the mybatis due to fill is to inherit the parent class with generics, reflection to the id of the type of Object, mybatis also don't know what type, only in Long assignment, learn together, have different opinions, please advise, as shown in figure

CodePudding user response:

nullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnull