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

Implement Ancestry Layer-wise feature API #605

Merged
merged 3 commits into from
Sep 6, 2018

Conversation

KeyboardNerd
Copy link
Contributor

Ancestry now has the per-layer feature information instead of per-ancestry feature information.

@KeyboardNerd
Copy link
Contributor Author

KeyboardNerd commented Sep 5, 2018

We need to have proper test infrastructure. The previous code doesn't work at all but passes all test checks. Now it's fixed though.

Copy link
Contributor

@jzelinskie jzelinskie left a comment

Choose a reason for hiding this comment

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

some nitpicks in general, but this is overall looking okay. once we get everything in, it might be worth doing some cleanup

api/v3/clairpb/convert.go Outdated Show resolved Hide resolved
api/v3/rpc.go Outdated Show resolved Hide resolved
Ancestry

ProcessedBy Processors
Features []NamespacedFeature
// TODO(sidchen) deduplicate the Layers.
Copy link
Contributor

Choose a reason for hiding this comment

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

is this something we want to do? won't the different layers have different context?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Well, the problem here is that Ancestry has Layers field, which contains a list of Layer, and AncestryLayer also has Layer. The information is duplicated. I just don't really know a good way to deduplicate these.

Copy link
Contributor

Choose a reason for hiding this comment

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

Why not have both types be the same but leave the DetectedFeatures for each Layer empty when it isn't AncestryWithContent?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I remember the design is that: Every struct, when returned, MUST have all fields filled to represent the whole information. Therefore, leaving DetectedFeatures empty will indicate that the Layer has NO detected features.

database/models.go Outdated Show resolved Hide resolved
}

return awf, true, nil
// By the assumption of Ancestry Layer Index, we have the ancestry's layer
// index corresponding to the index in the array.
Copy link
Contributor

Choose a reason for hiding this comment

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

This should really be in the Session interface doc comment for FindAncestryWithContent.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Well, this is an implementation detail for the ancestry_layer table. Here, I'm using the ancestry_index as the key to associate features to ancestry layers.

For people who implements this interface, they don't need to know what ancestry_index is. All they should do is get corresponding features for each layer in the Ancestry. They can do it in different ways, for example, query layer-wise feature directly using a single query.

Copy link
Contributor

Choose a reason for hiding this comment

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

You're totally right.

ProcessedBy Processors
Features []NamespacedFeature
// TODO(sidchen) deduplicate the Layers.
Layers []AncestryLayer
Copy link
Contributor

Choose a reason for hiding this comment

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

We should comment here about the order of the layers.

Feature extraction algorithm is changed to associate features with
ancestry layer. Database is updated to keep the relationship.
@KeyboardNerd KeyboardNerd merged commit 2bbbad3 into quay:master Sep 6, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants