For those eager for the newest things, we invite you to try an Early Access Program for DataGrip 2018.2. As many of you know, these builds don’t require a license as we want to encourage everybody to try the new features out before the official release.
New SQL formatter
Thanks to everyone who shared their ideas, we hope that now DataGrip will be able to meet the needs of lots more different code styles. This is a feature we strongly need feedback on, so, please, try out our new formatter and tell us if your specific cases are not covered. We are still working on new clauses to add . The start of the EAP program is the best moment to make DataGrip better!
SQL Log
First of all, now you’ll see every query that DataGrip runs in the console output. Whether it’s a user’s SQL or something DataGrip needs to run internally: check the Output tab to understand what’s going on.
Secondly, literally all queries from the IDE are now logged in a text file.
To open this file go to Help -> Show SQL log.
Source code migrations
Now, to update the source code of any of the other objects just double-click on them and make the needed changes. The gutter (the panel to the left of the text editor) will highlight the changes you’ve made. Pay attention to the toolbar: now there is Commit button.
Once you’ve pressed Commit, the migration dialog appears. The SQL code to update the source code is generated there.
Query plan diagram
A diagram-based view is now available for the query plan.
To view it, press the button on the toolbar after you invoke Explain Plan action. Let us remind you, that it’s available in the context menu of the query in the SQL console.
Run SQL on a schema
Before, the only way to run the script was executing it from the context menu of the corresponding SQL file. Now you can use a more intuitive way: choose the datasource or the database you need and invoke Run SQL script from the context menu.
That’s all for today! The release is going to be interesting, isn’t it?
DataGrip team.
I think the only thing missing in the formatter is the ability to disable the main BEGIN … END indentation for procedures/functions.
Elated to see some new attention given to the formatter! Thank you…
I have two concerns with the subquery behavior.
Here’s an example of current behavior:
LEFT JOIN (
SELECT
a.attribution_event_key,
a.customer_id,
a.event_datetime,
…
) s
I would like to be able to do this:
LEFT JOIN (
SELECT
a.attribution_event_key,
a.customer_id,
a.event_datetime,
…
) s
There are 2 differences here, which I would like to be able to implement but cannot even with new formatter.
1. subquery indent is relative to start position of prior line — not end position of prior line. Thus the subquery indent is the same no matter whether it is in a join or a left join or a cross join or a left outer join etc.
2. close parentheses is at same position as line preceding begin parentheses, same as is conventional in many programming languages.
Darn — whitespace is not preserved here. Hopefully my description is clear enough.
Using underscores in place of white space, new + current formatters:
LEFT JOIN (
__________SELECT
______________a.attribution_event_key,
______________a.customer_id,
______________a.event_datetime,
______________…
__________) s
I would like to be able to do this:
LEFT JOIN (
____SELECT
________a.attribution_event_key,
________a.customer_id,
________a.event_datetime,
________…
) s
Also, seeing issues with ANDs inside ON clause in joins. It aligns relative to start of ON clause, but we should be able to set it to do just 1 indent relative to start of prior line.
Bad:
JOIN_lkp.media_source_ms_ON_ms.event_source = l.event_source
____________________________AND ms.media_source_hash = l.media_source_hash
____________________________AND ms.channel IS NOT NULL
Good:
JOIN_lkp.media_source_ms_ON_ms.event_source = l.event_source
____AND ms.media_source_hash = l.media_source_hash
____AND ms.channel IS NOT NULL