-
Notifications
You must be signed in to change notification settings - Fork 440
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
More UpdateReleasedBinariesJob Refactoring #16425
base: master
Are you sure you want to change the base?
More UpdateReleasedBinariesJob Refactoring #16425
Conversation
af577a3
to
3e8b25e
Compare
# building a hash to avoid single SQL select calls slowing us down too much | ||
# We record BinaryRelease attributes in this hash of hashes to be able to compare them later on. | ||
# This is an optimization so we do not have to fetch BinaryRelease individually from the database. | ||
# FIXME: This is exactly what ActiveRecord::Associations::CollectionProxy does no? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no, activerecord has always full objects in memory
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You talk about putting the full record into the hash, I talk about not using the hash at all...
BinaryRelease.transaction do | ||
# Populate the old_binary_releases hash | ||
repository.binary_releases.current.unchanged.find_each do |binary| |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the limit override is missing again, this will increase easily at least one hour of runtime again.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is a "limit override"?
new_binary_release.binary_releasetime = time | ||
|
||
# Set defaults for versions/release | ||
# FIXME: This could also happen in the database instead... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we don't want to modify old database entries if possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not necessary as the default in the code is there since we create those entries...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hm, quite a lot of changes. We should verify on real life data what this changes. It would be very challenging to fix the database entries later on again.
On Montag, 1. Juli 2024, 16:38:35 CEST Henne Vogelsang wrote:
@hennevogel commented on this pull request.
> BinaryRelease.transaction do
+ # Populate the old_binary_releases hash
repository.binary_releases.current.unchanged.find_each do |binary|
What is a "limit override"?
The .limit(0). from my speedup patch.
Otherwise the default 1000 limit leads to a really long time running loop.
…--
Adrian Schroeter ***@***.***>
Build Infrastructure Project Manager
SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nürnberg, Germany
(HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev
|
Sorry, no idea what you are talking about. This is your original patch right? https://github.com/openSUSE/open-build-service/pull/16366/files |
3e8b25e
to
849df05
Compare
With a little bit more realistic data.
Now that we have attribute aliases we don't need different methods to build the hash key anymore. BinaryRelease and the hash we receive from the backend have the same keys...
Instead of building a hash build a `BinaryRelease` directly using the backend hash.
This attribute is *always* assigned a value in the one and only place we ever create a BinaryRelease: UpdateReleasedBinariesJob set_release_time! was unsused throughout the code base...
It's only used once throughout the code base. Use a speaking variable instead.
Yes we process these "items" but the whole set of this will be the current BinaryRelease of Repository after we are done.
Clarify what is going on and why we do some things.
No need to store the whole object, we only need the ID.
Specs for flavor/binary_maintainer attribute assignment and specs for the release_package and on_medium associations that get built.
849df05
to
8a3c10e
Compare
No description provided.