What's New in DataGrip 2024.1
Over the last few years, we've received tons of feedback from users who say that they don't understand the concept of sessions and that this functionality has contributed significantly
to DataGrip's learning curve. Here are several examples:
The project-first and separate-console-session model is way over the top overkill. This model makes opening and executing a simple SQL file a real chore. If I just want to open and
execute a script I have to first create a project, then add the file to the project, then open a console, then open a session, and then attach the file to the session. What a gigantic
PAIN.
Coming from SQL Server Management Studio, DataGrip's UI is a lot more complex. In SSMS you basically just have servers, queries and results. In DataGrip there's sessions and consoles
and scratch files, etc., etc., making the tool much less intuitive for new users.
Some of the way the UI works is clunky and non-obvious. When I have to select a console to run a script on, it's not entirely clear to me why I have to do this or what the
ramifications of the selection are. This shouldn't really be the default behavior.
In DataGrip, "session" is a technical term that refers to the container for a connection. In other words, connections can be established, stopped, and re-established within one
session. For each connection, there is one session.
The ability to attach sessions is a powerful mechanism, but in the majority of cases, users just need to set the context (data source and database or schema) for the queries to be run.
Starting from version 2024.1, users will no longer need to manually choose which session to run queries in, and this will be the case for all types of queries. Sessions are still there
under the hood, but you won't need to worry about them.
Let's take a deep dive into how this change affects DataGrip's main use cases.
