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

Tabulate failed_deps and index it #60

Open
riastradh opened this issue Apr 16, 2024 · 0 comments
Open

Tabulate failed_deps and index it #60

riastradh opened this issue Apr 16, 2024 · 0 comments

Comments

@riastradh
Copy link

As suggested in #56:

All that said, it might be better to use a separate table to obviate the need for formatting and parsing and make queries easier to write (with indices to speed up both directions -- find who's breaking a package, find which packages are broken by a package):

CREATE TABLE failed_deps (
    dependent INTEGER REFERENCES results,
    dependency INTEGER REFERENCES results,
    PRIMARY KEY(dependent, dependency)
) WITHOUT ROWID;
CREATE INDEX failed_deps_i_dependent ON failed_deps (dependent);
CREATE INDEX failed_deps_i_dependency ON failed_deps (dependency);

Though this takes a little more coding to adapt bulktracker than simply adding the index, it would likely speed up the display of a package results details page of a failed package like https://releng.netbsd.org/bulktracker/pkg/17647093.

(It would also be more reliable than the current getPkgsBrokenBy query, whose LIKE test could be confused if, e.g., there were both py311-xyz-1.2.3 and xyz-1.2.3 packages in the build. I don't know if this happens now but I certainly can't rule it out.)

bsiegert added a commit that referenced this issue Apr 21, 2024
FailedDeps used to be only failed, but there can be indirectly failed
dependencies as well. This is a bug that has been in the app for years!

I hope that this addressed the discrepancies in terms of the number of failed
dependencies in general.

There is still a bug around the "Breaks" counter. Left a TODO for now.

This will eventually be obsoleted by the fix for #60.
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

No branches or pull requests

1 participant