Let me be clear - this is just baseline testing that's only valid for similar data patterns, same cardinality, and so on. Plus it's currently using EXPLAIN, so we're working with estimates, not actual execution data.
But from my experience, this is low-hanging fruit for catching regressions that could break your application without you noticing. The performance work you're describing is the real nitty-gritty database management - the deep optimization work that truly makes or breaks an app.
For regression testing I struggle to see how a new SQL only test runner improves over a project’s existing testing systems. I think any project using a database should have integration tests that combine testing application logic with their database access queries. Your system does some explain checking but to me it feels tenuous if it’s worth the complexity required to dump all the queries my app may perform to text / YAML and adding yet another test runner in CI.
I think one interesting angle would be to integrate your assertions directly into Postgres as a plugin. That way, you can spy on every query issued in any test framework, dump the text automatically, and prove additional assertions about the query plan index use perf etc, regardless of the user’s primary language. That would also get you out of needing to build 1000 different integrations for all the programming language / ORM combos in the universe. If you don’t want to do a Postgres plugin you could also do this as a Postgres wire protocol proxy.
Hey, thank you for follow-up. Really appreciated. This is why I decided to go out and show RegreSQL.
You're absolutely right that in an ideal world, every project would have solid integration tests covering their database access queries. That's the goal everyone should aim for. Unfortunately there again and again cases where developers are afraid of SQL and databases and it's not uncommon to see very simple things sending applications to crawl.
As for the second point, that's a direction I would love to get. Whatever it can be directly, as part of open source or service is something to be decided - but tracking the trend data there would provide a lot of value indeed.
For now the syntax is not fully compatible - but my goal is to add https://github.com/boringSQL/queries (library behind SQL files parsing) to better align on it. It's definitely on my radar
At this point it supports initialization through the fixtures systems (like inline SQL or SQL files). At the moment they have fixed order, which might lead to some limitations, but I'm already thinking about some pre/post test setup hooks and full schema handling as well (for full schema reloads).
Plus I have whole set of other requirements where RegreSQL suddenly seems to be a good solution.
And without sounding cliche - Thank you for the comment! This is exactly why I forced myself to go public and get this level of feedback.
No cliche at all - I'm in the same boat, showing my stuff online was way out of my comfort zone!
I was postponing proper, dedicated performance testing for some time and would really love to up my game in that regard.
I'm very happy with pgTAP approach of running stuff in transaction and rolling them back after the test - how this works in RegreSQL?
Would love to provide feedback and test the hooks when you will be working on them. I'm mostly interested in performance testing and my use case would be to run them on CI and compare to previous metrics stored somewhere in order to fail CI when performance regressions are introduced.
For now only fixtures support transaction as cleanup options, but that's a good point that tested queries might also modify the queries.
I will definitely reach out, just give me bit of time to mentally recover from the exposure and got some meet ups where I promised to deliver some presentations and they will consume a lot of my spare free time.
The primary direction is to make RegreSQL part of CI/CD pipelines. In theory in can be run against production DB, but I believe it needs much more work to provide real value there. Thank you for the comment!
OP here - I do agree some of the problems that come with SQL/ORM queries are pretty horrendous and that's exactly where I would like RegreSQL going. For now I can't promise the particular direction, but comments like this are the reason why I pushed myself to release it and keep it beyond my own playground. Thank you!
Lived through it and while it might be similar, Microsoft had monopoly at that point (90% and higher share in personal computers - depending on the market). Apple is nowhere near that.
Apple is a monopoly due to their closed ecosystem. They do have a monopoly on headphones that properly work with iphones, operating systems that properly work with apple computers, operating systems and application delivery mechanisms that work with iphones, etc. They could get rid of their legal problems by being more open and supporting open standards, but they don't want to. So as a monopoly, they have to be forced...
"They should add a simple new heuristic to determine an abusive monopoly. If a company is imposing a volume surcharge instead of a volume discount to its biggest customers, it means there exists an abusive monopoly and regulatory intervention is needed.
There is absolutely no reason in a well functioning market for this to occur."
it seems awfully similar.. MS using their dominance in the OS market to establish dominance in the application software market vs apple using their mobile phone to establish dominance in smart watches, etc.. the scale is a bit different since we have the duopoly in the mobile market, but it still doesn't seem like something we want.
It was around the time Apple was about to go bankrupt when Microsoft had about 95% share.
Compare this to iPhone activations of new phones which is at 33% and declining [1]. Which means Android's market share of 70%+ is going to get larger over time.
No, the article you linked specifically says this is because of increased quality and fewer new features reducing the rate at which users upgrade. Apple still has roughly 60% of the installed user base in the US.
It's not about a monopoly. That word never occurs in the document. It's about interoperability and nurturing a market.
I quote from the EU document
> connected devices of all brands will work better on iPhones. Device manufacturers will have new opportunities to bring innovative products to the market, improving the user experience for consumers based in Europe.
About developers:
> The measures will accelerate their ability to offer a wider choice to European consumers of innovative services and hardware that interoperate with iPhones and iPads.
The DMA defines gatekeepers as "large digital platforms providing so called core platform services, such as for example online search engines, app stores, messenger services" and lists their obligations prohibitions. Apple is one of them because it's sufficiently large.
Smaller companies are not gatekeepers and are out of the scope of the DMA.
AirDrop has 100% monopoly on iPhone. iPhone has 0% other ways to share files via bluetooth than AirDrop.
As a user, I must be able to switch platforms at the end of the lifespan of a phone or Mac. So, buy a non-mac computer and then later a non-iPhone phone. So things need to interoperate.
That position from the EU is genius because it’s capitalism at its highest form. (Next is, all Windows apps must work on Macs, sounds like a joke but you’ll notice we already live in a world where they’re all webapp/electron, so it’s literally not a problem).
This is really funny. Seriously? Sharing files _over a particular protocol_ is the scope of your monopoly? Going further: your claim isn't even true. Any app can write data to a bluetooth connection. So the monopoly is even narrower than that.
But from my experience, this is low-hanging fruit for catching regressions that could break your application without you noticing. The performance work you're describing is the real nitty-gritty database management - the deep optimization work that truly makes or breaks an app.
For that there's no silver bullet.
reply