yosql-website/content/sql/structure.md

   1 ---
   2 title: Structure
   3 date: 2019-06-16T18:33:06+02:00
   4 menu:
   5   main:
   6     parent: SQL
   7 categories:
   8   - SQL
   9 tags:
  10   - repositories
  11   - files
  12   - structure
  13 ---
  14
  15 In order to call your SQL statement, a Java class must be created that contains methods for each of your statements. `YoSQL` will try to detect which repository your SQL statements will end up in. Based on the [inputBaseDirectory](/configuration/files/inputbasedirectory/) configuration option, your project structure could look like this:
  16
  17 ```
  18 <inputBaseDirectory>/
  19 └── user/
  20     └── getAllUsers.sql
  21 ```
  22
  23 Based on the above example, `YoSQL` will determine that you want a method called `getAllUsers` in a repository called `UserRepository`. Use the [basePackageName](/configuration/repositories/basepackagename/) option to change the base package name for all generated repositories. Together they will form the fully qualified name `<basePackageName>.UserRepository`.
  24
  25 ```
  26 <inputBaseDirectory>/
  27 └── internal/
  28     └── user/
  29         └── getAllUsers.sql
  30 ```
  31
  32 Nested package structures are supported as well - they are simply interpreted as subpackages, that are appended to the [basePackageName](/configuration/repositories/basepackagename/) option to form the fully qualified name `<basePackageName>.internal.UserRepository`.
  33
  34 ```
  35 <inputBaseDirectory>/
  36   └── user/
  37     └── vips/
  38         └── findSpecialUsers.sql
  39     └── getAllUsers.sql
  40 ```
  41
  42 Nesting repositories within other repositories is supported as well - `YoSql` will create two repositories for the above example: `<basePackageName>.UserRepository` with a method called `getAllUsers` and `<basePackageName>.user.VipsRepository` with a method called `findSpecialUsers`.
  43
  44 ```
  45 <inputBaseDirectory>/
  46 └── internal/
  47     └── user/
  48         └── getAllUsers.sql
  49 └── user/
  50     └── findUser.sql
  51 ```
  52
  53 Mixing nested and non-nested repositories work as well. The above example will generate the two repositories `<basePackageName>.internal.UserRepository` and `<basePackageName>.UserRepository`.
  54
  55 ```
  56 <inputBaseDirectory>/
  57 └── allQueries.sql
  58 ```
  59
  60 Smaller projects might just want to use a single `.sql` file that contains all of your queries. In case none of your SQL statements change their target repository in their [front matter](../sql-files/), all queries in the above structure will end up in a class called `<basePackageName>.Repository`.
  61
  62 ```
  63 <inputBaseDirectory>/
  64 └── internal/
  65     └── user/
  66         └── vips/
  67             └── findSpecialUsers.sql
  68         └── getAllUsers.sql
  69 └── user/
  70     └── findUser.sql
  71 └── lotsOfQueries.sql
  72 ```
  73
  74 Mixing all options is of course supported as well - we recommend using any structure that best fits to your project/team. One statement per file makes it easier to quickly find single statements, however grouping multiple statements together in one file might make sense for multiple reasons, e.g. a statement might have multiple variants based on the used database or any other set of statements that are usually changed together as a single unit.