FAQ
Licensing
Section titled “Licensing”What is a seat?
Section titled “What is a seat?”A ‘seat’ is a is a licensing unit used by dbLinter.
The number of licensed seats determines the maximum number of users that can be registered for a tenant.
Furthermore, a seat is reserved for each unique combination of the following attributes of a session:
| Attribute | Description |
|---|---|
| Email address | The email address of the dbLinter user used to connect to the dbLinter REST API. |
| IP address | The public IP address used to connect to the dbLinter REST API. |
| MAC address | The first enabled MAC address of the client machine. This may change when switching between network connections. |
| OS user | The operating system user name used to connect to the dbLinter REST API. |
This definition enables an unlimited number of tools to open sessions on a single machine, with only one seat reserved.
How many seats do I need?
Section titled “How many seats do I need?”The basic idea is to licence dbLinter for each developer working with a tenant configuration. The seat metric is simply a way of minimising misuse.
If you’re wondering how many seats you need, simply count the number of developers who will be working with dbLinter. Apart from very small teams using a large number of CI/CD runners in the cloud, the number of reserved seats will not be a limiting factor.
In any case, using local CI/CD runners is an effective way of reducing the total number of reserved seats.
For very small teams, it is advisable to licence an additional seat for CI/CD runners, to ensure that the number of seats is not exceeded during local development or CI/CD job execution.
Is a Web GUI session reserving a seat?
Section titled “Is a Web GUI session reserving a seat?”No, only sessions used for checking code and running tests reserve seats.
Who opens a session?
Section titled “Who opens a session?”| Tool | Open Session Event |
|---|---|
| dbLinter VS Code Extension | On activation of the extension. |
| On session expiration while running checks or tests. | |
| dbLinter CLI | On start of a check command. |
| On start of a test command. | |
| SonarScanner | On start of a check run using the dbLinter SonarQube plugin. |
Who closes a session?
Section titled “Who closes a session?”| Tool | Close Session Event |
|---|---|
| dbLinter VS Code Extension | On closing VS Code. |
| On reload window. | |
| dbLinter CLI | On end of a check command. |
| On end of a test command. | |
| SonarScanner | On end of a check run using the dbLinter SonarQube plugin. |
| dbLinter Repo | On expiration of a session. This is a logical change based on the server time. Session are considered expired when the value of Valid Until is in the past. See also Active Sessions. |
What is the TTL of a session?
Section titled “What is the TTL of a session?”This is configured in the dbLinter Repo per tenant. The default value is 1800 seconds. The value can only be changed by a product administrator.
Can access tokens be shared?
Section titled “Can access tokens be shared?”Yes. In fact, that’s what we’re doing with the anonymous tenant. All anonymous dbLinter users share the same access token. This token only has the DB-Developer role.
However, access tokens are personal. Therefore, you also need to share your email address (username) and tenant name. This is necessary when running dbLinter in a CI/CD pipeline.
For optimal security, it is advisable to use separate access tokens, limiting each one to a single tenant and the necessary roles.
What happens when the number of seats is exceeded?
Section titled “What happens when the number of seats is exceeded?”| Tool | Impact |
|---|---|
| dbLinter VS Code Extension | An error is logged. Problems are no longer being reported. SQL-based tests cannot be run. Neither can CLI commands. |
| dbLinter CLI | An error is logged and CLI stops with an error. |
| SonarScanner | An error is logged and SonarScanner stops with an error. |
Data And Privacy
Section titled “Data And Privacy”Where is my code processed?
Section titled “Where is my code processed?”The code is always analysed locally. This means it never leaves the local network.
For example, when you check the code in VS Code or with the CLI, it is analysed by a language server that runs locally on your machine.
What happens with the data read from my databases?
Section titled “What happens with the data read from my databases?”Data read from the database are used within checks and SQL-based tests to report rule violations and propose quick fixes or migration scripts.
There are no further uses for the data read.
Is dbLinter changing the data in my databases?
Section titled “Is dbLinter changing the data in my databases?”No. Never.
However, a SQL-based test may generate a migration script in the VS Code editor. To create missing foreign key indexes, for example. In order to run such a script, you must connect to a database and execute the script.
In any case, dbLinter cannot change data in your database automatically.
Is dbLinter changing my code?
Section titled “Is dbLinter changing my code?”Yes, when applying quick fixes.
However, you are in control. You decide which ones to apply. You decide to save or revert a change.
In any case, it is recommended that you use a version control system such as Git so that you can see the changes applied by dbLinter’s quick fixes.
Are quick fixes always correct?
Section titled “Are quick fixes always correct?”No, we cannot guarantee correctness.
However, we have defined Principles for Quick Fixes and implemented unit tests to reduce the risk of bugs. But we cannot guarantee bug-free code.
Which components communicate with components outside of my local network?
Section titled “Which components communicate with components outside of my local network?”The language server is the only dbLinter client component that communicates with components outside the local network. Specifically, it only communicates with the dbLinter REST-API.
What client-specific data does dbLinter store outside of the local network?
Section titled “What client-specific data does dbLinter store outside of the local network?”The following table shows the client-specific data stored by dbLinter.
| Component | Data Group | Details |
|---|---|---|
| REST-API | Log | Messages on open session, close session, sent emails. May contain data from session group. |
| Repo | User | Users (email, display name, password hash), tenant roles, access tokens (name, validity period, token hash). |
| Tenant | Tenants (name, session ttl), subscriptions (plan, validity period, number of seats), rules1, validators1. | |
| Config | Configs (name, description, include/exclude patterns), ignored test results (identifier, comment), custom parameters, enabled rules, connection infos2 (name, username, password, jdbc url). | |
| Session | Active and historised sessions (tenant name, config name, email, start time, valid until time, end time, client type, ip address, mac address, os name, os version, os user name, java version) | |
| Log | Log messages associated with code in the database, may contain data from session group. |
1 only for tenants with professional subscription
2 can be managed locally, either fully or partially
What is my email address used for?
Section titled “What is my email address used for?”We use it for the following:
- authentication
- authorisation
- sending emails as part of dbLinter workflows, for example
- confirmation emails
- password resets
- changing email addresses
- notifications about tenant access requests
- notifications about expiring access tokens
- contacting you if we encounter any unexpected behaviour
Will my email address be shared with third parties?
Section titled “Will my email address be shared with third parties?”No.
Errors
Section titled “Errors”Feature is not enabled for the current access token. Why?
Section titled “Feature is not enabled for the current access token. Why?”This error message is produced by the language server. This occurs when the access token does not have the necessary dbLinter roles to run the requested operation. The same thing happens when an error occurs when reading the configuration, resulting in no roles being found for the access token.
Check the logs for errors.
Typical root causes are:
- Invalid Remote Access settings.
- Exceeded number of seats.
Common
Section titled “Common”At what point is the configuration read?
Section titled “At what point is the configuration read?”The configuration is read from the dbLinter repo when opening a session.
Is a fully on-premises subscription planned?
Section titled “Is a fully on-premises subscription planned?”Not yet.
From a data and privacy perspective, we believe that dbLinter is suitable for use in an enterprise environment, since code analysis is always performed locally. This means that neither the code nor your database data ever leaves your local network.
Before we can consider providing an on-premises offer for dbLinter, we need to understand why the current SaaS model is difficult to integrate into your enterprise environment.
Please get in touch so that we can discuss your concerns. We are confident that we will find a suitable solution. Thank you.