To inverse dependencies of Dao

[tesshucom]

Overview

Dao dependencies will be improved. There is no immediate impact on current functionality. That's required for future modifications.

Goal

Preparation for future modifications. Arrangements will be made so that some SQLs can be automatically switched to dedicated SQLs in a specific DB. Mainly to speed up scanning.

Non-Goal

This pull request does not include query rewriting. Change only the mechanism without changing the existing processing.

Details

Broadly speaking, there are three fixes related to Dao dependencies.

• Change to inverse AbstractDao dependencies
• Split dao package into three packages
• Add dialect to switch part of Mediafile for each DB

Change to inverse AbstractDao dependencies

It used to be like this:

Abstract classes are deprecated in favor of dependency injection. The class name will be changed to TemplateWrapper.

Split dao package into three packages

This is not required, but the package will be split. There are advantages to both splitting and not splitting. The advantage of splitting is that it is easy to understand.

• base : Contains Helper, Utils, and Wrapper classes. Many are directly related to Spring or Liquibase.
• dialect : Newly created package related to DB dialect. Spring's dialect is not enough. Alternatively, gimmicks for "clever" SQL partial switching will often introduce complexity. Therefore, It is assumed that the entire Dao method (a series of SQL processing) will be rewritten. Some Dao will work by injecting the module class here.
• dao : Traditional Dao. Ideally, your Service classes should only access this package.

Add dialect to switch part of MediafileDao for each DB

For example, MediafileDao looks like this:

There are about 12 methods extracted in DialectMediaFileDao. There is a high possibility that speeding up these queries can be expected by replacing them with queries that are highly dependent on the DB grammar.

• Processing that has already been implemented has been moved to AnsiMediaFileDao. An equivalent method exists in HsqlDBMediaFileDao, but Ansi delegate is used internally now.
  • If the profile at startup is HOST -> HsqlDBMediaFileDao
  • If the profile at startup is URL, JNDI-> AnsiMediaFileDao
  • In other words, the queries executed are the same, only the processing path is different, now.
• From now on, all we need to do is write a query optimized for HSQLDB in HsqlDBMediaFileDao.