This post is to notify of a potential breaking change in our next release. This notification is for developers who have built applications that connect to a MySQL database and have initialized their connections using the SQLConnection type without explicitly choosing MySQL as the subclassed connection type. This issue will only affect a small number of Bungee Developers. This change will roll out in our next preview release on or around July 22nd and will be in the preview build for the standard two weeks. We’re choosing to announce the change as early as possible so that affected applications can be modified if needed.
Why the change?
In a recent release we updated our SQLConnection type to support connections to PostgreSQL databases. In the future we plan to enable connectivity to even more SQL databases. As a result, we’ve designed the SQLConnection type as a superclass for the specific database connection type that you’ll be using, whether it be MySQL or PostgreSQL or some other database in the future. By keeping the SQLConnection as a superclass you can connect to multiple data sources as well as dynamically swap the supporting database in your application.
Here’s the scenario where you run into this issue. If you have created a field of type SQLConnection – either explicitly or as a VAR – and have either allowed it to be nullable and not initialized it; or initialized it as SQLConnection; then by default the system would connect to a MySQL database without any issue. This is actually incorrect behavior and caused a bit of a loophole that developers have potentially been using for the past couple months. The breaking change is that a simple SQLConnection type can no longer connect to a MySQL database by default – it must be explicitly initialized as a MySQL connection type.
What do I need to do?
What you’ll need to do is go through you database connection code and look for any types that are initialized as SQLConnection that haven’t been specifically initialized as MySQL. In the builder you would see the following:
Note in the green area that the MyDBConnection field is set to be of type SQLConnection, and is nullable. However notice in the red box that the default value has not been set. See the following screenshot for the correct settings:
The Default Value has now been set to Object and the type is a new MySQL.
Another scenario where you could have an un-initialized SQLConnection is in a variable definition inline in the code. See the following screenshot:
See how I have created a new var named DBConnection2 and it’s of type SQLConnection but in the red box, I haven’t defined the default value. See the following screenshot for the correct setting:
Again; the Default Value has now been set to Object and the type is a new MySQL.
To re-iterate, the changes above are for those users that have been using the SQL connection up till now and have been connecting to a MySQL database without initializing the connection type specifically as MySQL. I would anticipate that there are only a small number of you that are affected. If you use a MySQL database, take a look at your code and double check.
How should I do this in the future?
So, going forward what should you do as a best practice for creating database connections in Bungee? Well, as I mentioned before, the reason we have the base SQLConnection type is to enable dynamic and easy swapping of the underlying database for your application. In all reality, this is most likely a very un-common scenario. The most efficient way to create the connection is to create your connection objects or vars directly as type MySQL or Postgres rather than SQLConnection.
Hopefully this is helpful for those of you currently connecting to a MySQL database. If you have any questions please post a comment directly to me on this post, or post on our forums.