Fork me on GitHub

see screenshots


@caskolkm: can you provide the code for the queries?


(defn get-archived-company
  "Looks in the history for a retracted company"
  [db host company-id]
  {:pre [(db? db)
         (entity? host)
         (long? company-id)]}
  (q '[:find (pull ?e pattern) .
       :in $ ?host ?e pattern
       [?e :host/belongs-to ?host ?tx false]
       [?e :company/name _ ?tx false]]
     (d/history db) (:db/id host) company-id company-pull-pattern))
Note that: a company is deleted when both name and host removed


@caskolkm: one issue is that you’re specifying the scalar find specification . - you would probably see both names but at present you’re limiting it to only a single value returned.


@bkamphaus: yes and no, without the

in the console it shows the same


[:find (pull ?e [*])
 [?e :host/belongs-to _ ?tx false]
 [?e :company/name _ ?tx false]]


it’s weird because it pulls information based on a entity id..


I’m not sure behavior for pulling from history is defined here in query, you can’t actually do it from the direct pull API — i.e. if you provide a history db input into pull directly you will see java.lang.IllegalStateException: Can't pull from history, or for entity java.lang.IllegalStateException: Can't create entity from history — in general, pull/entity not supported from history, as entities are derived from a database that contains only all assertions and retractions (applied) through the t of the database.


that’s weird, you can call it and it returns something?


@caskolkm: investigating the fact that it returns something as a bug, which I’ve repro’d. I expect that it should throw and we’ll fix this in a future version, but can’t promise that as of yet.


will the pull be supported in the future?


Depends on what you mean? pull specs in query and pull alone is definitely planned to be supported w/longevity you would expect for user facing API. What I mean specifically is a pull on history should fail/throw.


entities, either from entity (lazy traversing obj) or pull (pure data rep) are projections of datoms from a “current time” type db — they’re fairly nonsensical projected against history as any constraints that apply meaningfully to the entity no longer make sense, and e.g. retractions as part of an entity at once don’t make sense.


I think the more typical case would be to use history to figure out which t/tx values are interesting transition points for the entity, then use e.g. the as-of filter to see the entity at that point in time.


bkamphaus: hi, ocassionally have you use syslog for datomic logs in the official AMI?