Skip to content
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

[GIE] Support PathExpand with OPT=ALL_V_E in GIE #2841

Merged
merged 18 commits into from Jun 13, 2023

Conversation

BingqingLyu
Copy link
Collaborator

@BingqingLyu BingqingLyu commented Jun 8, 2023

What do these changes do?

As titled.

You can query a path expand with both vertices and edges preserved by specify the ResultOpt as ALL_V_E. e.g.,

image

Related issue number

Fixes #2776

@BingqingLyu BingqingLyu marked this pull request as draft June 8, 2023 11:30
@codecov-commenter
Copy link

codecov-commenter commented Jun 8, 2023

Codecov Report

Merging #2841 (0362a94) into main (bd89520) will decrease coverage by 2.72%.
The diff coverage is n/a.

Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff             @@
##             main    #2841      +/-   ##
==========================================
- Coverage   45.30%   42.59%   -2.72%     
==========================================
  Files          99       99              
  Lines       10668    10657      -11     
==========================================
- Hits         4833     4539     -294     
- Misses       5835     6118     +283     

see 16 files with indirect coverage changes


Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 086fa63...0362a94. Read the comment docs.

@BingqingLyu BingqingLyu marked this pull request as ready for review June 9, 2023 01:58
@BingqingLyu BingqingLyu changed the title [GIE/Runtime] Support PathExpand with OPT=AllVE in Runtime [GIE] Support PathExpand with OPT=ALL_VE in GIE Jun 9, 2023
@@ -20,7 +20,8 @@

public enum ResultOpt implements IntEnum<ResultOpt> {
EndV,
AllV;
AllV,
AllVe;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AllVe is strange, either AllVE, if the compiler complains, change everything to full name, ie., EndVertex, AllVertex, AllVertexEdge

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated as AllVE.

@@ -2175,6 +2175,7 @@ mod graph {
pub enum PathResultOpt {
EndV = 0,
AllV = 1,
AllVe = 2,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as the above AllVe

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated as AllVE.

SimpleAllV(Vec<Vertex>),
EndV((Vertex, usize)),
SimpleEndV((Vertex, Vec<ID>)),
AllV(Vec<VertexOrEdge>),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this is already a complex combination, we may want to include two enum, one is PathOpt, one is ResultOpt, as what we have defined in proto. namely,

pub struct GraphPath {
     path_opt: PathOpt,
     reult_opt: ResultOpt, 
     data: Vec<VertexOrEdge>
}

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some path may not need to preserve the whole path data of Vec<VertexOrEdge> (e.g., when EndV or SimpleEndV here).

@longbinlai longbinlai self-requested a review June 12, 2023 03:03
@@ -352,6 +353,9 @@ fn build_and_try_fuse_get_v(builder: &mut JobBuilder, mut get_v: pb::GetV) -> Ir
return Ok(());
}
}
} else if let physical_pb::physical_opr::operator::OpKind::Path(ref _path) = op_kind {
// make opt of getV after path expand as End.
get_v.opt = physical_pb::get_v::VOpt::End as i32;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

using std::mem::transmute ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

@@ -168,7 +168,7 @@ impl QueryParams {
}

pub fn is_queryable(&self) -> bool {
!(self.labels.is_empty() && self.filter.is_none() && self.limit.is_none() && self.columns.is_none())
!(self.filter.is_none() && self.limit.is_none() && self.columns.is_none())
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why remove labels.is_empty() here?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I removed this function as it is not used.

if let Some(edge_expand) = base.edge_expand.take() {
base_expand_plan.push(edge_expand.into());
if pb::path_expand::ResultOpt::AllVe as i32 == path.result_opt {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

use std::mem::transmute

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

// no label constraint
Ok(true)
} else {
if let Some(label) = label {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why we want to allow None label input in the function on the one hand, while throwing error while calling None label on the other hand? Simple pass &LabelId instead of Option<&LabelId>, no?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This function is to test if a vertex satisfied the label condition (i.e., filter by label):

  1. if without label condition, just return true (ignoring whether the label of RuntimeVertex is Some(&LabelId) or None);
  2. if with label condition, then it would further verify the RuntimeVertex label. And actually, RuntimeVertex will always carry the label for now (i.e., won't throw the error actually).

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know, then this function should not accept Option<&LabelId>, but let the called judge.

let mut result_collection: Vec<Vec<ID>> = vec![];
let mut expected_result_paths = vec![
// v1, e[1->2], v2
vec![1, 1, 2, 2],
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think making the element String, and if it is a vertex, turn ID into String, and if it is an Edge, turn (ID, ID) into string. This will make the results more clear.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

@BingqingLyu BingqingLyu changed the title [GIE] Support PathExpand with OPT=ALL_VE in GIE [GIE] Support PathExpand with OPT=ALL_V_E in GIE Jun 12, 2023
impl GraphPath {
pub fn new(entry: Vertex, path_opt: PathOpt, result_opt: ResultOpt) -> Self {
pub fn new<E: Into<VertexOrEdge>>(entry: E, path_opt: PathOpt, result_opt: ResultOpt) -> Self {
match result_opt {
ResultOpt::EndV => match path_opt {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This ResultOpt and PathOpt are both from pb, includes the whole path, like: pb::xx::xx::ResultOpt. In addition, I know ResultOpt::AllVe is generated, but can we avoid generating this name (that is inconsistent with our naming convention).

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

@BingqingLyu BingqingLyu merged commit e9af91a into alibaba:main Jun 13, 2023
25 checks passed
@BingqingLyu BingqingLyu deleted the path_expand_e branch June 13, 2023 06:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[GIE] Support 'ALL_V_E' option in 'ExpandPath' operator
4 participants