-
-
Notifications
You must be signed in to change notification settings - Fork 71
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
Release Trustfall v0.4.0-beta.0 to test the new APIs. #238
Conversation
The new query optimization APIs are here! I'm still working on documenting them properly but I wanted to release this beta to get some real-world testing and make the migration easier for Trustfall users, since there are some (extremely-minor) breaking changes for libraries that use @ginger51011 I'm not sure if your use case could benefit from additional query optimizations, but if it can, I'd love to get you as an early adopter and do a user test of the APIs and the docs! |
Ooh very nice! I'm in a bit of a crunch, trying to analyze data from my project to decide the next step, but I think I can see a use case (although optimizations for me rely heavily on other things). I'll see if I can find some time over Easter, but no promises! I was thinking that in my use-case, I have a spine of the graph from the beginning. Would query hints help me with providing this data to Trustfall early, or am I interpreting them the wrong way? Great work! |
Can you tell me more about what you mean by "spine of the graph" here? Query hints are meant to prevent situations like e.g. listing all neighbors of a vertex and then applying a property filter that discards nearly all of them. They allow the adapter to check for the existence of the filter before resolving the edge, so it doesn't have to bother to load vertices that will be discarded right away anyway. |
Aah I see, yes that does make a lot of sense yes. Come to think of it, I don't think I really understand in what order a graph is resolved. I mean yeah it starts at the root, but I suppose trustfall then goes through the graph calling the adapter methods when it wants to know things about a vertex? But what steps are taken for each vertex? In this case this might be interesting for me; I have some very expensive operations I might want to filter away early. I think you answered it but my first idea was "OK these vertecies will be evaluated no matter what, so we can just give them to trustfall in the beginning to optimize", but I don't think that applies here (more than as perhaps being able to give good hints). I'll try to get time to read the docs to figure out more! |
Currently, everything happens in order as written: top to bottom, left to right, except
Would love to hear more, either on a call or Zulip or something if that's easier. At the very least this is info that would be useful in the hints, if not outright being able to lead to a "smarter" adapter that does more of the work earlier. |
I've started writing some more docs, you can see some of the progress on this pre-release (feedback welcome and appreciated but not required!): https://docs.rs/trustfall/0.4.0-beta.2/trustfall/provider/index.html One thing I'm struggling with: if you were looking for optimization-related docs, where would you look? Where would you expect to find them? All the answers I've come up with so far have been unsatisfying. |
Also, I would particularly value feedback about the naming and documentation of the methods on this trait, which is central to the new optimization capabilities I'm adding: https://docs.rs/trustfall/0.4.0-beta.2/trustfall/provider/trait.VertexInfo.html |
No description provided.