Marten 2.6/2.7 and why we don’t support Sql Server (yet)

Between Lamar, a new Jasper release, and two Marten releases, I’ve been furiously trying to clear my plate of outstanding OSS work the past couple weeks to allow myself to concentrate on new efforts. As any experienced OSS author can probably tell you though, making a release is like leaving the screen door open and letting all the flies in as new GitHub issues and user questions come streaming in. My best advice — and some day I’ll take it myself — is to treat your OSS project as a continuous process rather than a series of short sprints.

I pushed Marten 2.6.0 with a lot of bug fixes and community pull requests on Friday. That seemed to open the door for more user issues, so I made an additional Marten 2.7.0 release yesterday with a couple pull requests I’d missed and some new convenience methods that had been requested for the event sourcing support.

The API’s are completely backwards compatible with a couple new additions in the event sourcing for finer grained live aggregation and additional options in the ViewProjection feature. I did let something slip by me in a pull request that negates binary compatibility, so you may need to recompile your code that uses Marten (optional arguments got added to a couple public methods and that breaks binary compatibility).

Thank you as always to the greater Marten community for all your contributions and ideas that continue to push Marten forward.

What about Sql Server/Oracle/MySql Support?

I’m frequently asked what it would take for Marten to support multiple database engines with the leading contender being Sql Server, unsurprisingly since this is coming from .Net folks. First off, I’m not opposed to doing this some time in the future when Sql Server’s JSON support catches up to where Postgresql is now. I’ve even promised our Sql Server-centric database team at work we will support Sql Server at some undetermined point in the future.

Putting any discussion of Postgresql vs. Sql Server aside, I do not believe that it’s feasible to run Marten on top of Sql Server 2016 at this time because:

• Marten depends on Postgresql and Npgsql specific constructs like array types that do not exist in Sql Server today
• Postgresql has quite a few JSON operators that have no equivalent in Sql Server 2016
• Sql Server does not have an equivalent to the Postgresql JSONB type for more efficient storage and querying
• Several features in Marten depend on being able to use embedded Javascript inside the database engine. Postgresql supports that with the PLv8 extension, but I’m not aware of Sql Server having an equivalent
• It would require a very heavy rebuild of much of the Linq parsing support, and I can’t even begin to explain how much that would suck
• It would just flat out be too time consuming at the moment

The one thing — and it’s a big thing — that Sql Server gets right over Postgresql in my opinion is its JSON operators are based around JSONPath. Assuming that Postgresql gets sql/json support in v11, and the next version of Sql Server comes with some of the missing features from Postgresql I outlined above, then I see a major Marten 3.0 release happening that finally strives to be somewhat database engine agnostic.

Don’t agree with me that Sql Server is lacking in the JSON support that Marten needs? Prove me wrong and build it yourself because there is no project like Marten for Sql Server 2016 today.