SpringBoot stepped on the pit to record some problems caused by Invalid bound statement (not found)

SpringBoot stepping on the pit record

Some problems caused by Invalid bound statement (not found)

When you happily build a SpringBoot project, use plug-ins to generate entity, dao, and mapper, write down the first Controller to try it out, but find that a simple query reports an error.

{
    
    
        "timestamp": "2019-03-18 16:21:48",
        "status": 500,
        "error": "Internal Server Error",
        "message": "Invalid bound statement (not found): com.xxx.dao.UserMapper.selectByPrimaryKey",
        "path": "/test"
    }

After investigation, it is found that the mapper folder does not exist in the target/classes/package name directory, which is a sad thing.

​ So we know the key, how to package the xml file under mapper. By consulting the information, we know that there are usually two ideas to solve this problem:

1. Put mapper in the src/main/resource directory, which will be packaged by default in this directory.

2. In the pom file

<build>

</build>

Inside the node, add a paragraph

<resources>
   <resource>
      <directory>src/main/java</directory>
      <includes>
         <include>**/*.xml</include>
      </includes>
      <!-- 是否替换资源中的属性-->
      <filtering>false</filtering>
   </resource>
</resources>

3. When you package, manually drop the mapper folder where the xml file is located into the target/classes/package name/ directory. You need to throw it once + run it once

I have only tried the following two of the above three methods. Although the above one did not exactly let go of the xml file, the storage and packaging of other types of files have been used, which will be discussed later.

Now let's talk about the second one. There is a hole here

Pit.1 Excessive configuration leads to picking up sesame seeds and losing watermelon

img

For example, you will see some of these configurations elsewhere. In fact, the files under src/main/resources will be packaged. If you unpack the comment in the figure, you will find that except the xml and properties files, nothing else is packaged (if you are using yml configuration, then yml It will not be packaged in), the blogger in the picture estimates that he also found that this code does more harm than good.

Here comes a problem. If there are only xml and properties files under the resource in my project, is this configuration harmless? Yes, it is true, it seems that templates and static can be packaged in.

After solving the xml packaging, we couldn't wait to continue packaging and running, and found that the error was still reported, emmmmmmm, which made people feel a little big. Opened the senior's project and found that under yml, mybatis was also configured

mybatis:
  mapper-locations: classpath:com/xx/xxx/mapper/**/*.xml
  type-aliases-package: com.xx.xxx.entity
  configuration:
    cache-enabled: false

Pit.2 Mybatis path configuration must be careful

When I saw the path, mapper/**/*.xmlfor some reason, I deleted the mapper by myself. /**/*.xmlIt seems to be the xml file pointing to the next level directory, but when you delete here, you will find that although xml It's packaged in, but your dao still can't find the mapper, or an error is reported.

The lesson of blood, children's shoes, remember that this path is: the directory where the package name/xml is located/**/*.xml

Guess you like

Origin blog.csdn.net/qq_43842093/article/details/123241356