Fork me on GitHub
#datomic
<
2017-01-18
>
tmorten00:01:21

It would I think, as it would also retract the link => event/_bids for instance...

tmorten00:01:55

when I say remove, I mean "retract" 🙂

sova-soars-the-sora00:01:30

@tmorten Ah are you providing the entity IDs yourself? I have not done it that way. I have simply provided the name and the value and I let Datomic resolve which EID it is.

tmorten01:01:29

No, I'm not. I'm using the db.fn/retractEntity however.

tmorten01:01:51

Just wondering if that will break the "ref" association from the other entity...

tmorten02:01:10

I found a bug in some of my logic that was causing the issue. Thanks for your help, though, @sova

peterromfeld02:01:27

hi, is it possible to query when a :db/id was created? == tx of :db/id

sova-soars-the-sora03:01:53

anytime @tmorten . glad you got it resolved. so db.fn/retractEntity just needs the eid? that is nice.

tmorten03:01:28

Correct. It is very nice

peterromfeld05:01:31

i guess not since :db/id is just one part of the index (entity) and you can't transact a db/id on its own i think, so only with the rest A/V/op you have a tx.. well i can always use [?e _ _ ?tx]

andrethehunter09:01:14

Is it possible to update multiple entities in a single transaction? something like:

(d/transact conn {:db/id [123 126] :my-entity/value “YAY”})

robert-stuttaford10:01:17

@andrethehunter not the way you’ve declared it. (d/transact conn [{:db/id 123 :my-entity/value “YAY”} {:db/id 126 :my-entity/value “YAY”}])

andrethehunter11:01:45

@robert-stuttaford what if the entity ids are not known and need to be found? a "nested" query. something like: (d/transact conn {:db/id [[:find ?e :where [?e :my-entity/value "Nay"]] :my-entity/value "YAY"})

andrethehunter11:01:21

the only way I've found was to create a datomic function via db/fn and then use that in two transactions

andrethehunter11:01:33

this seemed overly complicated and verbose

andrethehunter11:01:38

is there a simpler way?

robert-stuttaford11:01:20

what problem are you trying to solve by doing it this way, @andrethehunter ?

robert-stuttaford11:01:34

do you need to find and update it inside a consistent transaction?

robert-stuttaford11:01:55

if not, surely (let [id (d/q …)] @(d/transact conn [{:db/id id …}])) is sufficient?

tmorten14:01:02

@andrethehunter: if you don't know the entity id, then you could also use the lookup ref (hopefully you have another identifier in your entity).

pesterhazy15:01:32

@andrethehunter I'd also be curious what you mean by "need to be found". Maybe you could give an example?

tmorten15:01:02

My approach has been to generally ignore entity IDs and use lookup refs in their place. I'm guessing most people do the same?

stuartsierra15:01:58

Lookup refs are generally easy to work with. There's one place you can't use a lookup ref: In the same transaction that created the entity you're looking up.

karol.adamiec15:01:25

@tmorten i sway to the oposite, lookup refs throw, finding entity id myself gives me finer control over what happens

karol.adamiec15:01:10

but maybe someone could elaborate on pros and cons?

pesterhazy15:01:34

I agree with @tmorten, I always use lookup refs

pesterhazy15:01:55

and treat entity ids as a sort of implenetation detail

stuartsierra15:01:19

Both have their uses. Most Datomic API functions will accept either an Entity ID or a lookup ref.

Matt Butler16:01:14

Sorry to repeat my questions, unable find any answers online 🙂 Is there a simple way to clear the object cache for benchmarking sake? (Does releasing the connection work?) And on an unrelated note is is possible to limit a many cardinality ref relationship in datalog, so that the where clause only applies to the newest for example?

marshall16:01:38

@mbutler to clear the object cache i would recommend restarting your JVM

marshall16:01:30

@mbutler cardinality/many attributes don’t have any sense of ‘order’, they’re based on set semantics, so if you need to identify one element of the set you’d need to do it based on a secondary attribute of the referenced entity

favila16:01:45

@mbutler (d/shutdown false) may also work

Matt Butler16:01:58

Awesome, thanks :thumbsup:

Matt Butler16:01:22

I’ll have to think more about how to construct my query then @marshall maybe ask for the :db/ids of them all and get the first largest somehow. Alternatively may be better to flip the query on its head and traverse the ref in the other direction.

Matt Butler16:01:36

Thanks again 🙂

erichmond21:01:20

hey everyone, order of magnitude performance question. if we wanted to update a couple of hundred entities, modifying 2-3 attributes per entity, I assume that update would happen in the ms range, not the s range, right?