I'm surprised that they published the more recent paper discussed in part 2 [0] since, IIRC, TAO has supported atomic transactions since at least when I was there a few years ago, but better late than never I suppose. I wonder if that means there's still hope that someone at the company will write a blog post about frameworks like:<p><pre><code> - EntSchema/EntPattern
- EntQL
- EntAction
- PrivacyPolicy
- Ent Deletion framework
- Ent consistency checkers/fixers (I forget the name of the framework/tool)
</code></pre>
It's sad to think that people's only glimpse into these tools is through <a href="https://entgo.io" rel="nofollow">https://entgo.io</a> which is a really crude approximation of the real thing due to Go's lack of generics and expressiveness. Imagine if such amazing tools could be used at actually ethical companies.<p>[0] <a href="https://www.micahlerner.com/2021/10/23/ramp-tao-layering-atomic-transactions-on-facebooks-online-tao-data-store.html" rel="nofollow">https://www.micahlerner.com/2021/10/23/ramp-tao-layering-ato...</a>
Tangentially related: On Facebook, "The average person is connected to every other person by an average of 3.57 steps."<p>Three and a half degrees of separation<p><a href="https://research.fb.com/blog/2016/02/three-and-a-half-degrees-of-separation/" rel="nofollow">https://research.fb.com/blog/2016/02/three-and-a-half-degree...</a><p>When the article was published, there was a tool that helped to visualise that, and I was surprised but excited to see my estimate at 2.91, presumably helped by extensive travelling and diverse social circles.<p>I believe that if Facebook's success metric is connectedness, rather than profit, the world will benefit.<p>It's easy to look the other way, and claim that big problems (plastic in the ocean, climate change) aren't my personal responsibility. And for 3 degrees of separation, that's reasonable: Switzerland has no ocean, so can't fix the plastic problem. But here in New Zealand, I bike past the ocean every day. To "love your neighbour" and stop to pick up litter while biking home from work will have a direct impact on the lives of birds and fish right here, and a butterfly effect impact on the whole ecosystem.<p>By creating software tools like Tao to map the social graph, it's possible to measure the connectedness, and report these metrics. Links are also bidirectional (there's a "thank you" feedback loop) like Xanadu.<p>For comparison, Wikipedia's connectedness is 3.019 degrees of separation.<p><a href="https://www.sixdegreesofwikipedia.com/blog/search-results-analysis" rel="nofollow">https://www.sixdegreesofwikipedia.com/blog/search-results-an...</a>
Looking at TAO just as a data-model (instead of as a database system) and I'm really liking its simplicity.<p>But when you have a huge system like this, there's always engine-level rules (e.g. referential integrity) and business-rules that need to apply: for example, a Location-object can't "follow" a Comment and a PM cannot "check-in" to a User, and Human Users can't "friend" a declared bot User (I think?), given their overall design I assume the rules about what objects and associations can and cannot exist are enforced by the Association APIs when an association is created - so rejecting an invalid create-association request is straightforward, but how does it handle ever-changing business-requirements that can retroactively apply to existing objects and associations (e.g. supposing that FB decides to allow Human users to befriend bot users, so suddenly Mark Zuckerberg suddenly now has real Friend associations (shots fired), and then they decide to undo that policy change, how is the rule-change applied? What happens to the existing objects? What happens if two different physical FB servers running different versions of the software want to apply conflicting business rules?<p>Another thing I don't yet understand about using MySQL (or any SQL-first RDBMS for that matter) as a storage layer for an ostensible object/document system (hierarchical structured data) is that now you run into the object-relational impedance mismatch problem - which has many unpleasant solutions (e.g. using the EAV anti-pattern, which defeats the point of using an RDBMS in the first place - or going all-in with Codd's normalization and ending up with a rigid, strict data model schema design which is very difficult to update when business requirements change (i.e. using a table for each Codd relation (tuple) type to for each TAO object type and having to run ALTER TABLE ADD/DROP COLUMN every time you want to update the TAO object schema - which obviously does not scale. I assume each TAO object can be treated as a keyed blob with type-name (i.e. a 3-tuple of (id, type, blob) ) - in which case using an RDMBS is overkill and introduces many overheads, so why use an RDMBS? Especially as I understand that pretty much every major web-service will disable things like referential integrity constraints for the sake of performance (and you can't have a constraint w.r.t data in a blob column anyway).<p>...so I assume I'm missing something, but what?
Later in the article the name is explained in that TAO is used as short for "The associations and objects" and while it's clever and I'm not really offended it really should be TAAO.<p>Regardless, I'm surprised not to see anything about caching objects as application state using[1] or similar.<p>[1]<a href="https://www.php.net/manual/en/book.apcu.php" rel="nofollow">https://www.php.net/manual/en/book.apcu.php</a>