This provides compile-time analysis of your whole SQL schema.
It's a goddamned buggy disaster and the usability is basically zero, but the concept is cool.
I haven't found it to be buggy in my usage.
I'm curious what bugs you've run into, we have generally stopped being worried about the reliability of the diff scripts (we use those, though, we don't generate them on every deployment i.e. the .exe).
It just has a lot of jagged edges to cut yourself on.
1) Recompiling views - it does not properly figure out the dependency graph of the views before recompiling them, so if view A depends on view B which depends on table C and you're making changes to all 3 views, I have seen changes to View B not properly appear in View A.
2) Performance is bad on large projects. It's gotten better, but still the compile step is very slow. I have a legacy project that used to take 45 minutes to compile in VS2012, then "20 minute coin-toss success or crash" in VS2015, and now finally seems to work okay.
3) It uses the SQL server's server-level case-sensitivity for diffing schema. Most SQL servers have their schema case-insensitive (it's a dangerous server-wide change to change it). This means changes that things that differ only by case will not get published. That can produce cosmetic problems at the very least. We had a very embarassing bug where somebody was formatting a date in a view as "yyyy-mm-dd" which means year minute day. The change to "yyyy-MM-dd" did not get published.
4) The SSDT release for a build-server is really painful. Before it was accessible through some elaborate parameters in the MSBuild headless installer, but now it's been released as a Nuget package... and they forgot to include master.dacpac and msdb.dacpac, so if your databases have dependencies on those you have to copy them internally.
5) Releasing something that you have to access globally as a nuget package is... odd. I still haven't found the exact correct workflow for getting it onto our CI server. Everything I try feels like an ugly hack.
6) None of the build tool installers set up the needed environment variables, leaving you to figure it out yourself on every developer machine and the CI server. This includes path config, which will tempt you to reference the SqlPackage.exe by its fully resolved path... BUT
7) New versions of the SSDT suite break old versions. So don't reference the old version of SqlPackage.exe by its fully-resolved file path because it's broken.
8) It uses the SqlCmd.exe SQL preprocessor but many tools in the MS suite have minimal-to-no support for the directives. Imagine using a C editor where half the tools freak out at the sight of a #DEFINE. The powershell tool "Invoke-SqlCmd" in particular is a serious "unsafe at any speed" quality product.
9) The differ, in particular, fails at (8). Any inter-database references should be done with precompiler aliasing so you can swamp out that inter-database dependency... which is cool, but the differ then finds false-positives because it thinks.
[$(MyDatabaseReference)] in your source is different from [MyDatabase] in the running SQL server, when that's just before/after the token replacement.
10) Timing out on connecting to a database. When connecting to a large database, it can time-out when opening the connection. The setting to fix this is in the registry - there's no file or command-line setting to change it.
11) The Publish UI often opens a modal behind the main Visual Studio UI. Modal behind UI = "why is my window locked!!!"
12) Canceling a compile in-progress basically is the "crash the IDE" button.
I could go on and on...
That's not getting into a lot of the features that we see everywhere else in the MS stack that are conspicuously missing from Database Projects (like Nuget references).
Yep, the concept is pretty nice, the implementation can be harsh.
Our use case is SqlPackage builds the diff SQL, then we sanity check it using our custom code built on that parse for any DROPs / ALTERs and log/notify for confirmation
> Identify unsafe queries that could potentially lead to SQL injections
This feature seems like a perfect use case for static analysis and would be a great tool in addition to automated tests.
Not a panacea, but very nice regardless.
In addition to catching SQL errors, it generates type-safe Go wrapping code. Right now it supports PostgreSQL and MySQL.
I’m (obviously) a huge fan of the SQL first approach and hope more people adopt it for their own projects.
Disclosure: I'm one of the authors.
One detail that I really liked from Slick is that the compilation fails if your queries can't be performed against your database schema (think about missing columns, or wrong names or types).
While compile-time checks can be very useful, in my experience, there is nothing like having small integration tests that run against a real database which can easily be mounted by docker.
With the difference: it uses the PostgreSQL parser, not a generic SQL parser
Though it doesn't seem particularly maintained
I only heard about that in lectures but unfortunately could not really use it (sqlj was only compatible with Java pre-generics, so that was no option). Nice to see this idea revived.
The dynamic language camp would have no use for a tool like this.
Types and static compile-time checking catch different types of errors than tests do. I don't know about you, but I am not smart enough to write bug-free code consistently; I can use as much help as I can get.
In any case, it takes quite a bit longer to run my test suite than it does to compile.
Unfortunately, I tried to give it a spin, and it said:
ERROR: sqlvet only supports projects using go modules for now.
From a consumer viewpoint, I have a front page recommending episodes and a weekly summary. I get that, cool.
Now if I want to heart episodes to tell other listeners about episodes I particularly enjoy...I go to the website and search/submit the episode...I guess?
Anyway, I'm interested - I just wanted to share my first impression in case it was useful.