datasketches-tck [1] is ready and I initialized the repo with CPP + Java snapshots with their generator. We can add Go and Rust generators and snapshots there later.
[1] https://github.com/apache/datasketches-tck Lee, You can bring this topic to datasketches-tck's issue, and then we can continue the discussion there. So far, I can foresee each impl providing its own snapshot generator, and each impl doing its own serialization compatibility tests. For example, currently, datasketches-tck holds the snapshots and generators for the CPP and Java impls. We can bring Go's and Rust's there later. And, datasketches-rust tests deserialization compatibility with CPP and Java snapshots, as shown in [2] and other *_serialization_test.rs files. [2] https://github.com/apache/datasketches-rust/blob/3668658f3d0a415f4ee157cf769c8db024364603/datasketches/tests/bloom_serialization_test.rs That is, datasketches-tck would contain all specifications that should be followed by any DataSketches implementation, and provide tools and referenced test data for each impl to verify themselves. In this way, we handle the O(n^2) test matrix by: * datasketches-tck holds O(n) snapshots, one suite per language. * datasketches-rust and other impls, each test 1~n snapshot compatibilities as they evolve. The total complexity is still O(n^2), but for certain impl developers, they need only (1) provide/maintain the snapshot generator for that impl + (2) test other impls' snapshots gradually. So for developers focusing only on a certain impl, he/she would face an O(n) complexity. Best, tison. Lee Rhodes <[email protected]> 于2026年7月23日周四 04:39写道： > I have no objections to the name. A centralized repository dedicated to > this cross-language testing is appealing. > Nonetheless, I would like us to discuss the architecture of this repo and > the test scenarios it will address. > > Here are some of my initial thoughts. Please feel free to weigh in! 🙂 > > When this cross-language testing started we had only two languages: Java > and C++. It was a simple exchange of sketch images (*.sk) where Java would > load and test the images generated by C++ and C++ would do the reverse. > > Now that our library implements 6 different languages this simple scheme > has real limitations regarding scaling and maintenance. > > Perhaps now is the time to rethink our objectives and how we want to > implement cross-language testing. > Let me try to state what I think our objectives are: > > DATA: > Let: > > *L_a *:= a specific Language > *L_b *:= a different language > > *Sk(S, T, L) *:= Serialization image of Sketch *S*, using test algorithm > *T*, created by Language *L* > > *{T}* := a range of test algorithms > > > - For every sketch type *S_i* implemented in *L_a* it should generate > a range of sketch images of test algorithms, *{T}*, or > *{Sk(S_i, {T}, L_a)}. * The S*_i, T,* and *L_a* of a specific *Sk* > could be documented in the sketch name (or in metadata somehow). > - It might also be useful to document the release version of *L_a *that > generated the sketch and possibly other information. > - For every sketch type *S_i *impemented in *L_b *it should read and > test *Sk(S_i, {T}, L_a).* > > This does not require every language to implement all sketches—that is > simply not feasible—but hopefully we will reach a point where most of the > languages implement at least one member of the key sketch families: > cardinality, quantiles, and frequency. > > We want to test each language's ability to correctly generate these sketch > images and its ability to read and verify images generated by other > languages. > > This implies multiple sets of sketch images generated by each of the > languages. Because we cannot rely on exact binary reproducibility of these > sketch images, I don't see a way around this. > > The above is largely based on our historical testing approach. > What if we enclosed each sketch image in a container that would have space > for additional metadata, like: > > - The release version of the generating language > - Code or Pseudo-code describing the generating algorithm > - Test criteria > > Ideally, a smart container could simplify managing all this testing so > that every language doesn't need to know what is inside; it just picks up > the container, runs the test using the given criteria, and reports pass or > fail. I don't know how to do this, but it is fun to think about. > > Thoughts? > > Lee. > > > > > > On Tue, Jul 21, 2026 at 6:04 PM tison <[email protected]> wrote: > >> Thanks for your feedback. After some consideration and discussion with a >> few contributors, I'm going to create the repo of name "datasketches-tck" >> which means DataSketches Technology Compatibility Kit. This follows the >> impression of Java's Technology Compatibility Kit [1] and for DataSketches, >> it would contain test suites of compatibility among datasketches >> implementations, including mainly the serialization format. >> >> [1] https://en.wikipedia.org/wiki/Technology_Compatibility_Kit >> >> The initial implementation contains serialization snapshot of Java and >> C++, and we shall be able to add Go's and Rust's snapshots later. The >> generator is already present at [2] while I'd cut the code into one >> generator per language. >> >> [2] >> https://github.com/apache/datasketches-rust/blob/ee6e1cc432555c3562274ec36fc2dd6419b96701/tools/generate_serialization_test_data.py >> >> Naming is hard and it takes all this time to figure out how to name the >> repo to define its proper scope. >> >> I'd share the link to the initialized repo on the list this week or the >> next. Welcome to drop your comments if you have any additional ideas. >> >> Best, >> tison. >> >> >> Filippo Rossi <[email protected]> 于2026年5月26日周二 01:28写道： >> >>> Sounds very good! >>> >>> I think this will be a great way to validate the sketches serialised >>> from datasketches-rust, which currently are untested across the language >>> barrier. >>> >>> Thanks tison! >>> >>> Best, >>> Filippo >>> >>> On Mon, May 25, 2026, at 16:48, tison wrote: >>> >>> I'm going to create the repo and demonstrating the tasks, as well as >>> integrating datasketches-rust with it in recent weeks :D >>> >>> Best, >>> tison. >>> >>> >>> tison <[email protected]> 于2026年5月20日周三 09:41写道： >>> >>> Hi, >>> >>> I'm seeking a consensus to have a datasketches-snapshots repo for >>> hosting code and snapshots for delivering >>> https://github.com/apache/datasketches-rust/issues/10 >>> >>> Previous discussion - >>> https://lists.apache.org/thread/5ppjzrc151n387n4xfgpx1cxnhcv2sbk >>> >>> The first step would be generating snapshot and save them for reusing in >>> CI. >>> >>> Then we can review the generator and test cover matrix later, for issues >>> like >>> https://github.com/apache/datasketches-rust/pull/132#pullrequestreview-4319258129 >>> . >>> Best, >>> tison. >>> >>> >>>
