-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tools for joining Query objects #1658
Comments
IMO the HashSet methods should get us virtually all of the way there, and are familiar and idiomatic to Rust. Implementing those features on queries should be fairly easy: don't be intimidated if you want to try your hand at this. |
I'd like to try this (a canidate for my first open-source contribution :) ). However, I have some questions about the proposed behaviour. What happens when two queries are conflicting? Should it be assumed that this never happens since systems cannot have two conflicting queries as parameters? Should a join between a |
I think this is correct, but I would be sure to add tests for it.
I would prefer the latter, as it's much more ergonomic to work with and matches database joins more closely. There may be issues with this if we have
Relations are an (experimental) exception to this rule: you can have multiple |
Hmm. Yea I agree that it would be preferrable. I can't figure out any way to describe the type of that hypothetical join function though. From what i understand, it would require exponentially many implementations of the function (for all the different sizes of the pair of tuples, as well as placements of the similar component types in the tuples, if they are mutable, options etc. etc.). I dont see how to easily describe the type of the return value from the join function given its inputs. |
Right. I guess do it the first way then, and leave a TODO comment to change it once variadics are added to Rust. |
This was a bit more difficult than i initially thought. I have two main problems right now:
Any ideas? |
Hmm, I'm not sure. @BoxyUwU want to take a crack at this one?
This should be impossible in practice; our ownership model is a bit more sophisticated than Rust's since it works on a per-archetype level. I suspect the correct answer is to use |
# Objective - Add a way to combine 2 queries together in a similar way to `Query::transmute_lens` - Fixes #1658 ## Solution - Use a similar method to query transmute, but take the intersection of matched archetypes between the 2 queries and the union of the accesses to create the new underlying QueryState. --- ## Changelog - Add query joins --------- Co-authored-by: Alice Cecile <[email protected]>
What problem does this solve or what need does it fill?
As users attempt to filter their data more finely in more complex applications, they may need to combine data from multiple queries in order to get precisely the data they need.
In the simple cases, adding more parameters and types to your query is the correct choice. But this fails when:
What solution would you like?
The standard relational database tools and/or set operations should be added, providing a set of
(Query, Query) -> Query
functions or methods.The tools provided by
Option<C>
components already should be a heavy inspiration for the implementation and handling of the possibly ragged tables produced.What alternative(s) have you considered?
We could provide for this behavior at the type level (see
Or
and the proposedNot
query filters from #1471), allowing you to merge queries in complicated ways using the type system. This is less flexible and results in extremely complicated nested types, but does in theory mean we can restrict the data faster.As a workaround, you could extract the list of entities in each query, perform the set operations on those entity lists, and then use
query.get
to extract the desired entities and data from each query separately.Additional context
This came up in the context of #1627 with @BoxyUwU, discussing how to search for entities that have two parents. We can't sensibly have two
Relation<ChildOf>
types in the type parameter of a singleQuery
argument without a great deal of API complication, but looking for intersections etc. of the same relation across multiple entities is a sensible and common operation.The text was updated successfully, but these errors were encountered: