Has anyone thought of using the Pull API like a GraphQL query for client-side systems?

@mruzekw - Are you familiar with DataScript? https://github.com/tonsky/datascript

@wei, that seems long but connecting to datomic does take a while

With dynamo, a minute or so

Remember that datomic peers have a more active role than jdbc clients

I assume they need to pull still some segments to get started

they need to download the database roots, all idents, and the live index

I'm struggling a little bit with figuring out how to use conformity with transactor functions. Particularly as it seems that edn parses ' in a way I wouldn't expect: (edn/read-string "['[db]]") returns [' [db]] instead of core/read-string which returns ['[db]], so the code (particularly for the datomic query in my tx function) will not read correctly into edn.

Hits me after I ask, (quote [:find ...]) is the solution to the ' problem

Hi, I have two questions related to datomic’s infrastructure and provisioning: 1) Cognitect’s AMI: the used AMI dates back to May of 2014. Are there plans to release a new AMI with security updates and newer Amazon Linux version? 2) Logback config: To change logback.xml, should I simply replace it via the AWS EC2 Userdata?

After two weeks of work we now have a generic save function that can “update”, create and retract arbitrary nested data structures, originally returned from pull queries (and then modified by e.g. a web client). Is there any similar libraries available already for Datomic? Otherwise it could be an idea to open source it.

@teng: we have built something similar for comparing data coming in from external sources. curious how you approached it

@mruzekw Yes, om.next is basically that.

@jeff.terrell I have. I’ve been using it client side. I’m currently investigating best ways to communicate with the server, which is why I ask about Datomic

@danielstockton I like some parts of Om but am more a fan of Rum. Does om.next have isolate into different libraries?

Not sure I understand the question, sorry.

I wondered if I could take the reconciler part and use it with Rum instead of Om

Sorry, I don't have experience with rum at all. It might be possible to combine the two somehow. What do you think rum provides that om is missing?

Simplicity :) and full control

I find om (next) to be quite simple. Underneath, it's just plain react components, there isn't too much left when you take away the reconciler. For example, you can use a different templating library if you wish, although I prefer plain functions myself.

I haven't tried rum, perhaps I don't know the simplicity and control I am missing.

I can understand why it might seem overkill for simple applications with uncomplicated state. I also would like to see much tighter integration with datascript, instead of atoms + normalization helpers.

@stijn We define every “foreign key”, how the entities are related to each other + update/retraction/creation rights. Then we can perform all CRUD operations recursively to arbitrary data structures. Very neat. Took a week to write the 40+ tests!

@stijn How did you solve it?

@teng: the idea is that data coming in from e.g. XML files that needs to be updated in the database has a 'scope' which is basically a pull spec + a query that identifies the entities. If an xml file contains entities for all users with property x=a, the query will select the entities in the db that match the xml file scope. It might be that some files contain different details about the users, so the second thing needed is the pull spec to compare to. With that info we can generate adds and retracts by walking both the data that comes from the db and the data from the xml file.

so it's a bit different from your use case i guess

@stijn Interesting! Another thing. We are adding auditing now where we store when and who that updated the db, like this: {:db/id #db/id[:db.part/tx] :auditing/changed-by “system-x”}. I retrieve the tx information in separate queries (with help from @favila, so thanks again!) by using find queries that have “sub” pull queries. I couldn’t figure out how to retrieve the auditing data in the same pull query as the original one. Do you know if it’s possible to also retrieve tx related data (like auditing) for all attributes in a nested pull query, so that we don’t need to do several queries?

@teng Pull queries navigate relationships between entities. Transactions are entities just like any other. If you wanted to get both transactions and other entities in a pull query, you would need to have a :db.type/ref attribute linking the transaction entity to those other entities.

@stuartsierra Ok, thanks, I will try that!

@stuartsierra how would that look? one needs to explicitly define that in schema and then in every assertion/retraction provide that data? or can i grab txInstant from any entity by default?

@stuartsierra I’m not sure if that solves our problem. The tx id can vary between attributes for an entity. We can’t add an extra attribute for every attribute?!

atm i am having `[:find (pull ?tx [:db/txInstant]) (pull ?e [*]) :in $ :where [?e :order/identifier “asdf" ?tx]]`

and process that collection later to merge txInstant into order record.

Transactions are collections of datoms. A datom links an Entity, Attribute, Value, and Transaction. The pull API only knows about Entities.

If you wanted to navigate associations between Entities in your data and Transaction entities, you would need to add those associations in your data when you transact it.

@stuartsierra …by doubling the number of attributes in every entity?

That was not the use case I had in mind. What I have seen in the past is associations between Transaction entities and the top-level entities that are known to be "affected" by that Transaction. If you need the association at the granularity of individual attributes — i.e., individual Datoms — then you will need to use the query API.

@stuartsierra Ok. We need the granularity to be at the attribute level, so then I will just continue with the query API as you suggested. Thanks.