Context on FtM #1651

Hey all!

I just wanted to add some context to this PR on FtM, which adds Java language bindings.

So @simon and I have been having a series of discussions about the future of ftm-store in Aleph, and it’s OpenSanctions equivalent, nomenklatura.store.base:Store. The thing is that SQL is sort of a heavy-handed way to do what the ftm-store is meant to do: keep individual entity parts (call them fragments or statements, doesn’t matter), and return them in a grouped form if prompted.

I’ve been playing with the idea of using Meta’s rocksdb to do this as a sort of central entity server, using gRPC as a quick way for readers and writers to get entities and traverse the graph. Unfortunately a) rocksdb doesn’t have Python bindings, and b) this is sort of a high-performance, low-latency thing to do… so, the experiment has escalated into building a JVM FtM data server. It’s called zahir for now, but I’m not sure that’s a good name. We might look into the cost/benefit ratio of using it for OpenSanctions, and perhaps it could also be useful to Aleph as a replacement for ftm-store.

All in all, just wanted to explain why there’s weird Java bindings popping up :slight_smile:

— Friedrich

2 Likes

i am so looking forward to this :wink:

I AM BECOME ENTERPRISE, DESTROYER OF SOULS

Congratulations, now do Cobol! :sports_medal:

2 Likes