Bean Searcher released v3.7.0 version

Introduction

Many systems have requirements for list retrieval (such as: order management, user management), and the data that each list page needs to display often spans multiple database tables (such as the order number column in the order management page table comes from the order. table, the user name column comes from the user table), at this time, the domain class (or entity class, the class that is associated with the database table) created by our backend cannot form a one-to-one correspondence with the data to be displayed on the page.

 

Therefore, VO (View Object) is generated. It is between page data and domain classes. The data displayed on the page no longer needs to correspond one-to-one with the back-end domain classes, but only need to correspond one-to-one with VO, and VO no longer needs to be mapped with the data table. , it can be assembled in the business code. But at this time, the logic of the back-end is a little more complicated, because we not only need to parse the parameters from the front-end, but also deal with the conversion relationship between domain classes (or complex SQL query statements) and VO. Bean Searcher believes that VO no longer needs to be related to the domain class. A VO can not only correspond to the page data one-to-one, but also can be directly mapped to multiple data tables in the database (the domain class is different, it only maps to one table), and this new VO is called Search Bean.

 

Before the appearance of Search Bean, the retrieval conditions from the front end all need to be parsed and processed by business code (because ordinary VO cannot be directly mapped with the database), and the query results also need to be converted to VO again. After the Search Bean appears, the conditions can be directly expressed by the fields and parameters in the Search Bean, and directly mapped to the query statement of the database.

 

Therefore, the code in the back-end retrieval interface only needs to collect the retrieval parameters of the page, and the rest is all handled by the Bean Searcher, and the SearchBean it returns is the VO object required by the front-end, and no more conversion is required. .

 

And that's why Bean Searcher can greatly improve R&D productivity!

 

v3.7.0 update content

✨ Features

• Bean Searcher
  • Added dialect implementation to support SqlServer 2012+ SqlServerDialect 
  • New operator, see: https://github.com/ejlchina/bean-searcher/issues/38 OrLike 
  • Enhancement : Added interface to allow users to monitor slow SQL in code SqlExecutor SlowListener 
  • Enhancement : Added property to configure whether to enable style conversion during auto-mapping DefaultDbMapping underlineCase  驼峰->下划线 
  • Enhancement : Added a method to use database keywords to improve query performance when ignoring case queries Dialect hasILike()  ilike 
  • Enhancement : support conversion to enum (convert by enum ordinal) EnumFieldConvertor 整型 
  • Enhancement : Add a new attribute, you can configure whether to report an error when an illegal value cannot be converted, the default EnumFieldConvertor failOnError  true
  • Enhancement : Added a new property, which can configure whether to ignore case when string value matches enumeration, default EnumFieldConvertor ignoreCase  false
  • Optimization : normal SQL shows time-consuming execution, slow SQL log level is adjusted to and output associated entity classes SQL 日志 WARN 
  • Optimization , when the count sql is executed and the query result is, the list sql is no longer executed DefaultSqlExecutor 0 
  • Optimized and methods, their starting page numbers are also bound by page number configuration ( destructive update ) 参数构建器  page(..)  limit(..) 
  • Optimization : To add a default implementation, when a user defines a dialect, only one method must be implemented Dialect toUpperCase(..)  forPaginate(..) 
  • Optimization : use pagination parameter extractor by default DefaultParamResolver page 
  • Optimized count and sum retrieval, when there is no record statistics, return instead , and optimize retrieval performance again 检索器  0  null
  • Refactor renamed to FetchType#ALL  FetchType#DEFAULT
• Bean Searcher Boot Starter
  • Added a new configuration key to configure the slow SQL threshold (in milliseconds), the default is bean-searcher.sql.slow-sql-threshold  500
  • A new configuration key is added to configure whether to start hump->underline style conversion during automatic mapping. The default is bean-searcher.sql.default-mapping.underline-case  true
  • Added configuration key to configure whether to report an error when an illegal value cannot be converted, the default bean-searcher.field-convertor.enum-fail-on-error  true
  • Added configuration key to configure whether to ignore case when string value matches enumeration, default bean-searcher.field-convertor.enum-ignore-case  false
  • Support users to configure a Spring Bean to monitor slow SQL SqlExecutor.SlowListener 
  • Support user configuration to use Sql Server dialect bean-searcher.sql.dialect  SqlServer 
  • upgrade -> spring-boot  v2.6.8

Are you still asking what a Bean Searcher is?

• Come and see how it can increase your efficiency by 100 times: https://juejin.cn/post/7027733039299952676
• Come see why it is directly different from MybatisPlus: https://juejin.cn/post/7092411551507808264
• Super detailed documentation: https://bs.zhxu.cn/

If you feel good, click STAR ^_^:

• Github: https://github.com/troyzhxu/bean-searcher
• Gitee:   https://gitee.com/troyzhxu/bean-searcher