Repository navigation
Query::get_multiple for accessing multiple entities simultaneously from the same query #2276
Description
What problem does this solve or what need does it fill?
When working with queries, you sometimes need to access the data on multiple components at once. This is particularly frustrating if you require mutable access, due to Rust's borrow checking rules.
What solution would you like?
Add the Query::get_multiple(entities: HashSet<Entity>) -> HashMap<Entity, Result<[Elided](https://docs.rs/bevy/0.5.0/bevy/ecs/system/struct.Query.html#method.get_mut)>> method and the associated get_multiple_mut. By passing in a HashSet of entities, we can ensure that we never have mutable access to the entities at the same time.
Also add get_component analogues for this pattern.
What alternative(s) have you considered?
iter_combinations solves the common case, but other more bespoke access patterns certainly exist.
You can work around this by storing data, but that only works for Clone components.
@TheRawMeatball felt this should use a different API / impl:
it'd be more like a wrapper you put the query into
and then it'd pass out smart pointers wrappers of smart pointers
Additional context
#1470 may be easier to work around with this style of API.
It may make sense to use this implementation for iter_combinations in some way, but be mindful of perf as iter_combinations is likely to be used in tight loops for things like collision detection.
Activity
alice-i-cecile commentedon May 30, 2021
Unsurprisingly, a parallel API for direct world access is probably a good idea too.
[-]Query::get_multiple for accessing multiple entities simultaneously from the same entity[/-][+]Query::get_multiple for accessing multiple entities simultaneously from the same query[/+]alice-i-cecile commentedon Aug 4, 2021
rust-lang/rfcs#3100 treads similar ground, creating a trait for this style of functionality in the standard library. We could migrate this functionality to use that trait later once it's stabilized.
alice-i-cecile commentedon Dec 12, 2021
Duplicate of #2042.
burdges commentedon Jun 20, 2024
Just fyi, if you really really want access to multiple entries, then you might consider a cuckoo table. Those could've some
indexmethod which finds the positions for the key, and then you access those positions directly as if they were aVec. Any write accesses could bump buckets contents of course, but only into a few other buckets, whic the index still locates. I've long meant to write a cuckoo table crate, because there are a bunch of really cool optimizations, but not yet done so.alice-i-cecile commentedon Jun 20, 2024
Really neat data structure! Would the main benefits be performance?
burdges commentedon Jun 20, 2024
I'm unsure how performance works out, usually cuckoo filters wind up more memory efficent. I think few people use them because all the optimizations look more subtle than hash tables.
Afaik they work fine with the same good hashers and hash tables, like SipHash or HashBrown, but they're more sensitive to bad hashers, and some devs love plugging in bad hasher for speed.