[rc_hackernews]

My first two programming jobs out of college back in the early 2010's took the approach in this article. Albeit, with older technology.

This is bringing back old (bad) memories of the times where I was debugging stored procedures that called triggers that called the same stored procedures.

A lot of that was due to poor design and bad choices. Some of that was due to developers trying to fit processes and patterns into a language, i.e. SQL, that lacked the expressiveness for it.

I'm not a fan of this approach to say the least.

I'd be interested in hearing other's experiences with this though.

And I'm going to check out Fauna since it looks like a cool database and to see if anything has changed with this approach since I encountered it almost a decade ago.

[robsutter]

I remember those days too - my sins were T-SQL and I remember those headaches quite clearly.

One huge difference today is that you can actually unit-test user-defined functions and stored procedures using the same tooling you use for your application code. That lends itself naturally to integration testing, and so on.

I wouldn't necessarily recommend taking it to the property-based testing extreme like I did just to see whether it worked (it does).

[chrisjc]

> you can actually unit-test user-defined functions and stored procedures using the same tooling you use for your application code

Can you give an example of how this is possible, or what tools/services it's possible with? I can understand how it would work on UDFs, but not entirely sure how it would be possible for stored procedures, esp when they're often times doing something more complex than simple read operations.

[robsutter]

Sure - here's an example using Jest to test the logic in UDFs: https://github.com/fauna-labs/fql-utilities/blob/main/tests/...

You can use Jest's before[All] and after[All] to do any required setup and teardown per usual.

For Fauna, UDFs and stored procedures are synonymous.

[GordonS]

I remember doing the same almost 30 years back, copying data from an Oracle database to an MSSQL database.

It was a fairly limiting approach, performance wasn't great, and diagnosing problems was a total PITA.

Afterwards I did an integration using an antiquated version of BizTalk, which was all based on COM and to this day remains my most loathed software ever. It was way too complex, the UI was crap, it was flakey as hell, and ridiculously slow. Later versions got better, but it was a very low bar.

Later I used a Java-based Apache project to do an integration - I forget the name. It was actually really good, easy to use but also allowing full control.

Later still, I did some integrations using custom C# code based around WWF (Windows Workflow Foundation) - the UI in Visual Studio was horrendously slow and flakey, it was too complex to build your own pipeline segments, and difficult to diagnose issues in production. But it did work fairly well for simple stuff.

And then later still I used PowerCenter - I was the architect, so wasn't that hands on, but the PowerCenter guys liked it, and we ended up adopting it as our standard integrations tool, with hundreds of integrations across the company.

[meepmorp]

Was it Apache Camel? I used that a while back and liked how low hassle it was.

[GordonS]

Hmm, name doesn't sound familiar, it was a very long time ago tho.