Neither released v2.3.0 nor the built version of master pass the spec tests

[deinspanjer]

I really liked the idea of jd and wanted to port it over to support SQL engines.
I spun up a new project to do so and started working on implementing against the spec, but after hitting a few tough parts around supporting some format and translate options, I finally went back to seeing how jd itself handles them and I discovered that neither of these versions currently pass the defined spec test.

That plus the fact there hasn't been any activity on the project in months make me worry about the future state.
@josephburnett are you still working on the project? Do you have plans to finish up the next release and get it passing the spec tests as documented?

[josephburnett]

Hello @deinspanjer! I am still working on JD but only in my spare time. It's sort of a labor of love over many years, but I remain committed to it. The Spec was something that I started working on recently to make JD more formal. Tell me more about what parts of the spec you saw being handled incorrectly. I would be happy to jump in a straighten things up.

Also, tell me more about porting it over to support SQL engines! An interesting idea.

[deinspanjer]

Awesome! So happy to hear that.

I've gone ahead and made my repo public although it doesn't feel like it is quite ready for an initial release yet:
https://github.com/deinspanjer/jd-sql

At the moment, I am only failing one spec test when running the test cases through my internal JUnit suite.
I also wrote a spec test runner wrapper that can be called by the jd spec test, but I honestly haven't gotten back around to making sure it still runs properly after some heavy refactoring. One of those things to get done before release. :)

While trying to get the final test case passing, I decided to try running the current jd 2.3.0 against the spec test and it gets lots of failures.

I also tried running a locally built version of master and it got fewer failures but still had some.

The actual problem I hit that started all this was that I was trying to use the transform option jd2merge passing a jd native diff text that had the ^ "MERGE" preamble and jd throws an error that it isn't accepted. It does work on master with ^ {"Merge": true} but it is weird because the code sure looks like it is trying to check for a string value and accept it.

[josephburnett]

Hey @deinspanjer, a lot has changed since you opened this. I've done a pretty significant overhaul of the spec and test suite. Here's the quick version:

The spec is now implementation-agnostic. Test data uses format-level concepts — operation, options, expected_output — not CLI flags or exit codes. The idea is exactly your use case: an SQL implementation should be able to consume the same test data with its own harness. The Go test runner in spec/test/ is just a reference that maps the data to jd's CLI.

Translation and MERGE are out of scope. The jd2merge transform you were hitting trouble with — that's been removed from the spec entirely. The spec focuses on what makes the JD format uniquely valuable: human-readable structural diffs with set semantics and patching. Translation between formats (RFC 6902, RFC 7386) is left to individual implementations.

All spec tests pass. 70/70 on master right now. The test data lives in spec/cases/ with a README describing the format. Round-trip testing (diff, patch, verify) is built into the runner.

Other changes you'd care about:

• setkeys is now keys in the spec (cleaner name, reflects that it's about object identity, not just sets)
• Option conflicts are formalized — e.g. precision is incompatible with set semantics because approximate equality isn't transitive (breaks the math required for set membership)
• Error handling philosophy: static config errors must be rejected, data-dependent edge cases are explicitly documented as undefined behavior

Would you take another look at the spec and test data? I'm curious how it lines up with your SQL implementation now. Your project was actually one of the motivations for making the test data decoupled from Go.

[deinspanjer]

I will definitely try to get some time and attention on it sometime soon.

My repo hit a stable and "useful to me" phase and I stopped active development while getting heavy use out of it right now.

Happy to hear about the improvements!