I asked a question over on the old forum before I realized this new forum was here. In the meantime, I Dustin Getz pointed me towards the answer. Reproducing the question and the answer here for future searchers.
I’m wondering why Datomic Ions does not provide an equivalent of datomic.api/entity from the on-prem peer library.
I understand why the cloud API does not provide it; it would introduce a large number of implicit and synchronous network round-trips. However, as best as I can understand Ions, my code runs within a peer. I would expect ions to provide the same functionality as the peer library, instead of the client library.
Is there a gap in my understanding? Or is there some other reason why ions omits this functionality?
Dustin linked me to the following resources:
The summary is that while code running on ions should expect performance similar to that of the peer library, local development against Datomic Cloud still uses the database across the wire. There is a meaningful performance distinction between local development and production deployments. Restricting ions to the client library’s interface prevents users from accidentally depending on ions in-memory performance when you may wish to reserve the option to deploy an application as a client using the underlying wire-protocol implementation.
Entity API’s laziness should not be a problem given in-memory database access for deployed ions functions. Although I have not yet tried this, it should be possible to create your own entity-api on top of the q or pull functions. At some point soon, I may try it, but I’ll probably have 1) a eager-loading hint operation and 2) a debug flag for logging lazy & N+1 query waterfalls (like many Ruby on Rails performance debugging tools have). This way development over the wire will be slow, but functioning, and can be optimized with eager loading hints. In production, peer-like performance can be expected.
Hopefully these notes help someone else. If anyone has more info/thoughts, happy to discuss as well.