Matchday Advancement
The Controller's purpose is to automatically and periodically advance the matchday of all match rounds that have a proper configuration for the advancement.
In order to configure a match round for the advancement, the match round must fulfill the following criteria:
- all matches of the current matchday must be finished
- the matchday properties for the next matchday have been set (these can either be number or date based)
- there is at least one match in the future
- the property for the automatic advancement has been set to determine a periodic time at which the advancement will happen, e.g. each friday at 6 pm
If any of the criteria does not match the matchday won't be advanced any further. This can be the case at the end of the season of a match round.
Example Advancement 1 (constant time span)
Assume that we got a match round with the following matchday configuration:
| Current matchday start date | Current matchday end date | Next matchday start date | Next matchday end date |
|---|---|---|---|
| 01/01/2018 | 07/01/2018 |
When the controller advances the matchday for the first time we get the following result assuming that we got matches in the future:
| Current matchday start date | Current matchday end date | Next matchday start date | Next matchday end date |
|---|---|---|---|
| 01/01/2018 | 07/01/2018 | 08/01/2018 | 14/01/2018 |
Note that the time span of one week (7 days) will be retained for the new next matchday. Now we advance one more time:
| Current matchday start date | Current matchday end date | Next matchday start date | Next matchday end date |
|---|---|---|---|
| 08/01/2018 | 14/01/2018 | 15/01/2018 | 21/01/2018 |
The time span is still retained. If we assume that there are no more matches after the 21/01/2018 the next advancement will be the last:
| Current matchday start date | Current matchday end date | Next matchday start date | Next matchday end date |
|---|---|---|---|
| 15/01/2018 | 21/01/2018 |
As you can see, we still got a current matchday but no new next matchday because there are no more matches. This might be the case at the end of a season.
Example Advancement 2 (rotating time span)
If you don't want to advance the matchdays by a constant time span, you also have the possibility to choose two different time spans for the current and next matchdays which will then be rotated.
For this example we assume that you want to rotate the matchdays twice a week. Since a week has an uneven number of days we will end with two time spans of different length.
We start with the following matchday configuration:
| Current matchday start date | Current matchday end date | Next matchday start date | Next matchday end date |
|---|---|---|---|
| 01/01/2018 | 04/01/2018 | 05/01/2018 | 07/01/2018 |
Note that the current matchday has a time span of 4 days while the next matchday has a time span of 3 days. After the first advancement the matchday configuration will look like this:
| Current matchday start date | Current matchday end date | Next matchday start date | Next matchday end date |
|---|---|---|---|
| 05/01/2018 | 07/01/2018 | 08/01/2018 | 11/01/2018 |
Note that the former next matchday became the new current matchday. Therefore the new current matchday now has a time span of 3 days while the new next matchday has the time span of 4 days because the former current matchday also got this time span.
If we advance one more time the matchdays will rotate the time spans again:
| Current matchday start date | Current matchday end date | Next matchday start date | Next matchday end date |
|---|---|---|---|
| 08/01/2018 | 11/01/2018 | 12/01/2018 | 14/01/2018 |
Now the current matchday got its 4 days back and the next matchday its 3 days time span. This kind of rotation will always be kept with further advancement.
Installation
For running the TableStar Controller in a cloud environment, we provide docker images and helm charts on our docker registry.
Be sure to mount your specific application.yml, (if desired also logback-spring.xml) into the containers at /workspace/config.
If you would not like to use docker, locate your configuration files next to the jar-file. A rudimentary startup command for TableStar Controller could look as follows:
java -jar tablestar-controller-5.0.0.jar
Configuration
To change the configuration, edit the application.yml file which is located in the config subdirectory of the TableStar Controller installation.
Effectively you will only provide the connection information to the Sophora Server as well as the port the TableStar Controller uses.
See example configuration below.
Setting JVM Arguments
JVM arguments may be passed to the application via the JAVA_OPTS environment variable. Additionally, VM arguments may be specified in application.yml under the vmargs key.
If present in application.yml, the value is required to be single-quoted according to the YAML specification as in the following example:
vmargs: '-Xmx4096m -Dproperty="some value"'Otherwise the application might not start properly.
