Inline Expression

Motivation

Configuration simplicity and unity are two main problems that inline expression intends to solve.

In complex sharding rules, with more data nodes, a large number of configuration repetitions make configurations difficult to maintain. Inline expressions can simplify data node configuration work.

Java codes are not helpful in the unified management of common configurations. Writing sharding algorithms with inline expressions, users can store rules together, making them easier to be browsed and stored.

Syntax Explanation

The use of inline expressions is really direct. Users only need to configure ${ expression } or $->{ expression } to identify them. ShardingSphere currently supports the configurations of data nodes and sharding algorithms. Inline expressions use Groovy syntax, which can support all kinds of operations, including inline expressions. For example:

${begin..end} means range

${[unit1, unit2, unit_x]} means enumeration

If there are many continuous ${ expression } or $->{ expression } expressions, according to each sub-expression result, the ultimate result of the whole expression will be in cartesian combination.

For example, the following inline expression:

  1. ${['online', 'offline']}_table${1..3}

Will be parsed as:

  1. online_table1, online_table2, online_table3, offline_table1, offline_table2, offline_table3

Configuration

Data Node

For evenly distributed data nodes, if the data structure is as follow:

  1. db0
  2. ├── t_order0
  3. └── t_order1
  4. db1
  5. ├── t_order0
  6. └── t_order1

It can be simplified by inline expression as:

  1. db${0..1}.t_order${0..1}

Or

  1. db$->{0..1}.t_order$->{0..1}

For self-defined data nodes, if the data structure is:

  1. db0
  2. ├── t_order0
  3. └── t_order1
  4. db1
  5. ├── t_order2
  6. ├── t_order3
  7. └── t_order4

It can be simplified by inline expression as:

  1. db0.t_order${0..1},db1.t_order${2..4}

Or

  1. db0.t_order$->{0..1},db1.t_order$->{2..4}

For data nodes with prefixes, inline expression can also be used to configure them flexibly, if the data structure is:

  1. db0
  2. ├── t_order_00
  3. ├── t_order_01
  4. ├── t_order_02
  5. ├── t_order_03
  6. ├── t_order_04
  7. ├── t_order_05
  8. ├── t_order_06
  9. ├── t_order_07
  10. ├── t_order_08
  11. ├── t_order_09
  12. ├── t_order_10
  13. ├── t_order_11
  14. ├── t_order_12
  15. ├── t_order_13
  16. ├── t_order_14
  17. ├── t_order_15
  18. ├── t_order_16
  19. ├── t_order_17
  20. ├── t_order_18
  21. ├── t_order_19
  22. └── t_order_20
  23. db1
  24. ├── t_order_00
  25. ├── t_order_01
  26. ├── t_order_02
  27. ├── t_order_03
  28. ├── t_order_04
  29. ├── t_order_05
  30. ├── t_order_06
  31. ├── t_order_07
  32. ├── t_order_08
  33. ├── t_order_09
  34. ├── t_order_10
  35. ├── t_order_11
  36. ├── t_order_12
  37. ├── t_order_13
  38. ├── t_order_14
  39. ├── t_order_15
  40. ├── t_order_16
  41. ├── t_order_17
  42. ├── t_order_18
  43. ├── t_order_19
  44. └── t_order_20

Users can configure separately, data nodes with prefixes first, those without prefixes later, and automatically combine them with the cartesian product feature of inline expressions. The example above can be simplified by inline expression as:

  1. db${0..1}.t_order_0${0..9}, db${0..1}.t_order_${10..20}

Or

  1. db$->{0..1}.t_order_0$->{0..9}, db$->{0..1}.t_order_$->{10..20}

Sharding Algorithm

For single sharding SQL that uses = and IN, inline expression can replace codes in configuration.

Inline expression is a piece of Groovy code in essence, which can return the corresponding real data source or table name according to the computation method of sharding keys.

For example, sharding keys with the last number 0 are routed to the data source with the suffix of 0, those with the last number 1 are routed to the data source with the suffix of 1, the rest goes on in the same way. The inline expression used to indicate sharding algorithm is:

  1. ds${id % 10}

Or

  1. ds$->{id % 10}