Hi, running into a weird issue on datomic cloud. Where comparisons on float fields are failing to match, in the sample below from one of my devs, test-var is something like 123456.0. Even grabbing it directly from the db and handing it right back in the next query, isn’t matching.

(def test-var (first (ffirst (d/q '[:find (take 10 ?nga)
                              :where [_ :nga-can/nga-id ?nga]]
                         db))))
                         
                         
        (d/q '[:find ?e
       :where [?e :nga-can/nga-id test-var]]
  db)     

comparisons on floats are generally problematic due to imprecision (this is a generic issue in any language using IEEE 754)

that may not be your problem, but just something to be aware of

yeah I thought that that might be the case. But, even using the ‘same’ value seems to be problematic.

@eoliphant could it be NaN? that will fail even self equality tests

looks like it’s good ol IEEE floats at the end of the day

https://twitter.com/datomic_team/status/1158742202270572546

Hi all, how do I retract all entities match some filter. For example, the entitiy has a :date attr and I want to retract all entities where :date is in a given date range

(d/transact conn (map (fn [e] [:db.fn/retractEntity (:db/id e)]) (filter #(in-range? (:date %)) entities))) ?

there’s not really any notion of DELETE FROM table WHERE date >= ... if that’s what you’re looking for

Could somebody sanity check a model I came up with? We need to use a full-text search to find entities, and then return a bunch of attributes that are stored in Datomic. So I have created a query function as an ion that calls out to cloudsearch and returns a set of ids and scores. I then look up the id normally. The query looks something like this:

(d/q '[:find (pull ?e [*]) ?score
       :in $ ?query
       :where [(ions.cloudsearch/find-by-query ?query) [[?id ?score] ...]]
         [?e :generic/id ?id]]
     db
     query)

@matthavener Thanks. I wish google were better at finding this information

I would do a separate query to get the "entities"?

yes, you would use a separate query in that case. Though remember that those entities aren’t removed from the database, the history is intact; what you’re trying might be better done in your queries with a rule that filters :date after the date you’re interested in

if you’re attempting to get rid of old data to save space, datomic might not be the right fit for your problem

For now I think I do want to retract them. we want the history so we can always trace the data. thanks again

@jmiller If your cloudsearch request blocks I would say its a bad idea to do that in the query. Instead, why not issue the cloudsearch query, then take the results and pass them into the datomic query? We have a homegrown datomic cloud lucene integration that does something similar to this. Granted, the lucene indexes are relatively small (3gb) so its low overhead.