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

Allow rpm dependencies to be duplicated. #192

Closed
wants to merge 0 commits into from
Closed

Allow rpm dependencies to be duplicated. #192

wants to merge 0 commits into from

Conversation

simozhan
Copy link
Contributor

Simply deleted the unique constraint. If the dependency data is very big, maybe add a relationship table between rpm and dependency is better?

@erichuanggit
Copy link
Collaborator

I think what @lubomir proposes is ignoring duplicated dependency and storing only once. But current change will store multiple.

@ycheng-aa
Copy link
Contributor

From JIRA, "The goal is that anyone can take rpm dependencies and shove them into PDC without having to go through them and doing uniq(sorted()) on them.". It looks like ignoring duplicate dependencies could work. We unique it first and store. If we want record the dependencies precisely, maybe just add a field to record each dependency repetition number? I am not sure. At least I think we don't have to restore the whole information repeatedly.

@simozhan
Copy link
Contributor Author

simozhan commented Nov 2, 2015

When we import the rpm, some information is missing. For example in gok.spec
Requires(pre): GConf2
Requires(post): GConf2
I am just thinking if it makes sense to allow duplicates for easy extending Dependency in the future?

@lubomir
Copy link
Member

lubomir commented Nov 2, 2015

In an ideal world I would prefer to remove the duplicates. However, I think the proposed patch with removed unique constraint is fine. It should not cause much problems with amounts of data, as there will not be that many duplicates, and will save space by not using an index for the constraint.

I don't know if we need to handle different kinds of requires (pre versus post). If we do, that would be a different task, I think.

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.

None yet

4 participants