Primary and Embedded Updates
TIL how to update embedded documents at the same time as parent documents.
This makes sense when you look at the
data._source
of the Actor and see how the items are stored there.25 Replies
Data structure for example (5e actors)
Since
items
is expected to be an embedded collection, the .update
method does the dirty work of exploding out the array as individual updates automatically.
Setting an array in the update
method for data that isn't expected to be an embedded collection would simply override the array entirely.
Interestingly, this works just fine if you have multiple objects in the updateData items
array with the same _id
. Presumably each one is operated on sequentially.
Resulted in an item named Arrow +2.2
Would it be possible to update a parent but include a new child item as well? I'm trying to limit the number of round trips to the server so if I can condense it that'd be
Pretty sure definitely yes
yeah!
So
So (based off of memory) if I call an update with data that does NOT contain an ID it usually fails. How do you get around that?
if the
_id
is there, it's an update operation. but if not it's a createooh
Sweet!
So you've gotta have all the right fields present
for items, that's
name
and type
That's what I was hoping.
Yeah, I just remember running into issues with update(s) and not having an
_id
lol.So perfect! Thanks @calego
@ethck gave LeaguePoints™ to @calego (#1 • 1258)
NICE
documents rock
definitely helps in situations like this.
Ohhh ok, interesting, found this snippet:
so you could construct the ephemeral
Item
beforehand to more easily interact with its data, then toObject
it and push that into the update dataWhat's the difference between doing
CONFIG.Item.documentClass
and just Item
? Aren't they the same (usually)?CONFIG.Item.documentClass
would get you the system's item class, e.g. Item5e
Ah, and I assume that's probably the more preferred route, good to know!
its more bulletproof yeah, in case a system does something particular about its created items, this would run the right constructor and suchforth and so on, instead of only running the Core ones.
Makes sense.
BTW, this combined update is dangerous with unlinked tokens.
How so?
Updating single small piece of an item with it causes it to replace the entire item list with what's in the update. So you end up destroying all items and their data that you didn't include.
The joys of unlinked tokens, you know.