Exposed moving forward

Read this post in other languages:

Exposed started out a few years back at JetBrains, as a lightweight ORM/DAO written in Kotlin. It has since been used internally on a number of critical products at JetBrains, and despite being classified as a Team project on GitHub, it has garnered a large number of external users. 

While the main person on the project was doing his best to provide support and move it forward, we decided it was time to dedicate more resources to it. As a consequence, we hired full-time developers, a technical lead, and we’re working on making Exposed a first-class product. 

Today, we’d like to share our plans moving forward. 


A uniform API for 1.0

One of the benefits of Exposed is that it provides a statically-typed language which is similar to SQL, allowing you to easily query databases without the downside of using SQL strings in your code. The keyword here however is similar. There are cases when there is a significant deviation from SQL.

We want to try and bring the syntax as close as possible to SQL as well as remove some inconsistencies between the DAO and DSL approaches of Exposed. 

While this will introduce breaking changes, we believe that it is the right thing to do to set a strong foundation for Exposed moving forward. 

Reducing boilerplate

Much like with Kotlin, our goal is to reduce the amount of boilerplate code that needs to be written when working with Exposed. Currently this is not the case. There are definitely areas where we could reduce the overhead of having to write repeatable code. 

While we could certainly introduce annotations, much like Ktor, we want to avoid magic. It’s important for developers to know what exactly is happening, and how it’s taking place. We’re looking at approaches to meet these criteria. 

Long-standing issues

In addition to some bigger changes, there are a number of long-standing issues that need to be addressed. Our goal is to get to as many of these as possible over the coming months. Those that require breaking changes will be postponed to 1.0 or after. 

Release Process

Similar to what we did with Ktor, we’ll be moving Exposed to Semantic Versioning. We want to release 1.0 as soon as we have addressed some concerns around the API. The current timeframe is August 2024. Independently though, we’ll be moving to monthly releases to make sure that as issues are resolved, they are made available to you. 

Documentation and Samples

One of the main pain-points of Exposed is the lack of extensive documentation. To this end, we’re in the process of reviewing the existing documentation, restructuring and enhancing it, and we’ll be publishing it on the new Exposed website (which is also in the works). In addition we want to provide more self-contained samples that are easy to follow and learn from.

Moving to YouTrack

As part of processes being put in place, we’re moving the issue reporting to YouTrack. This will provide us with better ability to track, classify, and attend to issues. Existing issues on GitHub won’t be migrated as per our previous experience doing this with Ktor, we lose the author of the comments. In addition, there are a bunch of stale and outdated issues on GitHub that we’ll review and remove. New issues however should be logged in YouTrack.

We’re very excited about the many possibilities that Exposed can offer developers, and eager to continue to build on this library and provide the best user experience to you, our users. Remember that you can reach out to members of the team, as well as get support, on the Exposed channel on the Kotlin Slack. If you’re not on there, you can sign up using the form.

Thank you

The Exposed Team

image description