D/entity in ions?

Client API
1

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.

Cheers,
Brandon

3 Likes
2

It’s less about ions “omitting” something (a matter of perspective) than about supporting an API. Right. The peer API is not over-a-wire friendly, thus we developed the cloud client API. Ions support the cloud client API. This lets people write portable production programs that run as clients (many people do) or ions. When running as ions you get peer-like in-proc perf, even with what looks like multiple “round trips”. Thus the decision to write ‘as if in proc with db’ (i.e. considering those ‘trips’ free) rests with the application, not the API. This is better, once wires might be involved, as only you know your deployment intentions.

Datomic cloud client’s query and pull results support datafy/nav. This can get you pretty far. You can see that in action in REBL.

4 Likes
3

Thanks for the additional context.

I’ve still got to really sit down and study datafy/nav someday soon :slight_smile: