This is tough for us because we always wrote tests for human SQL not programmatic SQL. These editors generate all sorts of wacky queries and hit more untested parts of the code base, particularly the information_schema. The first step in this is getting a large swath of Database editors to really work. In the next two months we are focused on improving UX for two main tools 1) Database Editors 2) ORMs. What we need to do is be proactive with a wide variety of tooling to at least get a better sense of what works and what doesn't work. We've seen users churn because their tools are broken within the first hour of connecting them to Dolt. As we became more of an OLTP database with server capabilities we wrote a significant amount of tests to ensure that MySQL Clients would work with Dolt.Īs adoption has picked up we've started to see Dolt fail quickly in situations we just didn't really think about prioritizing before.ĭatabases sit in a complex stack ranging from simple clients to complex data science tools.
When we put a SQL Engine on top of Dolt we augmented our correctness work with a wide variety of hand written engine tests and the Sqllogictests.
When Dolt was originally a "Git For Data" CLI tool we really focused on making the CLI experience as flawless as possible with a substantial amount of BATs tests. Our current UX challenge is gettingĭolt to work perfectly within the first hour of use, enough time for developers to get to that first "wow experience" with diffs or merges.
Tableplus wacky software#
"production grade" software with performance, but to us, it includes user experience (UX). Dolt is on its way to becoming a production grade version-controlled MySQL database.
0 kommentar(er)
