Clojurians Log v2

Looks like they want to index their versions by year now

Haha... I had not thought of that! Maybe you're right—2026, July. Guess I'll have to wait and see how the next few releases are numbered 🙂

We are wrestling with this

The Maria 2.x db driver essentially figures out if it's talking to Maria or MySQL by checking if the version is less than 10

And the statement timeout syntax is different between the two

> checking if the version is less than 10 Absolutely vile.

I compared it to the windows 95/98 checks seeing if the version starts with 9 so that's why it went from 8 to 10

I've never heard of it and I will pretend I have never read it - my day just started, that's way too harsh news for the morning.

I don't know if that Windows thing is true, but I do know the reason files/directories that start with . are hidden in Linux and Unix is because a developer made a shortcut like isHiden = path[0] == '.'

Maybe... "monotonically increasing" numbers is ... monotonous?

> Looks like they want to index their versions by year now I mean, that kind of depends on what calendar one wants to believe in, and how much UTF one wants in the numbers. 26.7.0 could be 🐴.7.0 (it's the Chinese year of the Horse). Doing it this way is also with the times---LLMs love that emoji jazz.

Also, is it a tacit admission that the maintainers will abandon the connector as of 2099?

LOL on all counts there @adityaathalye 🙂

https://github.com/mariadb-corporation/mariadb-connector-j/blob/maintenance/2.7/src/main/java/org/mariadb/jdbc/MariaDbConnection.java#L126 here’s the offending bit in 2.7 where it doesn’t even mention it’s doing maria vs mysql behavior. it’s just intrinsically in that version check

https://github.com/mariadb-corporation/mariadb-connector-j/blob/maintenance/3.4/src/main/java/org/mariadb/jdbc/Connection.java#L76 vs 3.x where it directly consults if this is mariadb or not

Ouch!

There is a reason any library I publish today will be 2026.07.30 - This game isn't fun to play

reminds me strongly of rich's talk about semantic versioning

Think along the lines of, some other team needs support for a new schema, so they can just request it themselves and fill out a form with whatever configuration is needed, it'll automatically appear in dev but requires platform approval for prod. Something like that.

Ya, it's a pain in the arse lol

Generally the publisher should just be in charge of the schema, and be responsible for it. If you bring in the platform team to gate that, it slows everything down and other teams can't iterate and test and it's annoying for everyone.

The only exception is if you need compliance to whatever. Where the central platform should be able to assess the data and revoke access, hide the fields, encrypt them, etc.

Let's assume we are in a highly regulated, compliance heavy domain, with strict requirements around PII.

It makes sense for the producer to mostly own the schema but that schema does need to adhere to some light patterns established by the platform team, mostly around the event envelope.

Haha, I suspected as such. Yes then you need to retain some control and likely some structure to build more generic reports and logs and all that.

My experience is still that it's a huge pain though, but it's kind of the cost of compliance

What I

I think having a first level of schema, and then a meta-schema is probably ideal. For example the first schema dictates allowed shape, disallow extra keys, allowed value types, and so on. Then you also want a schema (part of the same or an extra one) that defines data-classification of fields, intended business use, etc.

Then each publisher can create a schema for a new event which is constrained already by those above ones. On that schema itself, they need to both define their data, but also classify it. The schema still needs approval by the central team, but like you said, not in devo, because that slows things a lot.

Lastly, I also recommend a global field registry, and then logic that searches for existing fields. Like say one person creates a "customer-name" on their schema. It's likely that events already exists that model customer-name. At schema creation, you'd want to say: this concept is already modeled like this? Want to use that? Else, why do you need to introduce a new representation of it?

So some fuzzy search on field names, so it would match agains customer, customerName, cust-name, etc.

From my past experience in similar situations I would prioritize making the ops side as seamless as possible. Things like making sure it's clear which teams own which schemas and if possible, being able to easily enable/disable if and when things break.

Anyone have any experience working with a cloud solution for this (saas or docker delivery) or is this something everyone is just hand rolling when they need it. I know Confluent has a schema registry but I think it's specific to their managed Kafka offering, not general use. And I doubt it has the self service features I'm looking for.

At my place of work where I've experienced this it was hand-rolled

What you're describing can't be fixed by a centralized repository with codeowners per subdirectories mapped to team and a PR always requiring signoff by a platform team member? Then your CI can turn this into whatever schema registry solution you want

I'm not sure. I think that's only addressing part of the problem, which is the approval of schemas. Maybe it slightly helps with discovery but only for technical staff. I'm looking for: • Monitoring the utilization of schemas. • Discovery, in part, driven by utilization. • Preventing a proliferation of similar schemas (review helps, but discovery matters too). • Tracking teams/systems that are existing nonconformists and fixing them. • Tracking new traffic that happens to contain breaking changes and correlating it to the source team/system.

I've had some experience with this problem and have lots of ideas knocking around my head, and I don't want to devolve into incoherent disjoint ideas I collected over time on the subject, but I'd be game to set up a time where we can have a chat about it because I experienced very similar pains, so DM me if you're interested

I'd check this article https://building.nubank.com/why-we-killed-our-end-to-end-test-suite/. They validate for each topic/endpoint the producer/consumer schemas, and validate that they are compatible. So for every change, it has to pass the schema validation against the schemas used in the deployed versions of the other consumer/producers related to the repo of the PR. Not bullet proof, but very useful at scale.