-
Notifications
You must be signed in to change notification settings - Fork 284
Conversation
It might be worthwhile to add some tests along the lines of |
usage_factor = pw.FloatField(default=1.0) | ||
|
||
class Meta: | ||
db_table = "usagefactor" |
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.
Does it need a separate model/table? Isn't it better to just add a field in LocalRank
?
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.
I'm unsure but maybe I know too little about the marketplace in general -> how does a usage factor relate to LocalRank? is a usage factor always accompanied by a local rank record? does one implicitly assume the other or can they exist independently? are the properties in the LocalRank used for the same purpose as the usage factor?
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.
@mbenke ^ ?
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.
LocalRank
is used basically for the same purpose as usage factors, i.e. provider choice.
SCHEMA_VERSION = 40 | ||
|
||
try: | ||
import playhouse.postgres_ext as pw_pext |
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.
Is this import required? How is it used here?
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.
it was added automatically by peewee_migrate...
Also, |
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.
Definitely not an expert on this, but here's a couple of nitpicks.
created_date = pw.UTCDateTimeField(default=dt.datetime.now) | ||
modified_date = pw.UTCDateTimeField(default=dt.datetime.now) |
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.
I assume that we somehow use these for tracking usage factors in time? If not, are they not somewhat redundant?
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.
these are inherited from BaseModel so, as standard feature of all golem models, so to say...
model.UsageFactor.provider_node_id == provider_id).first() | ||
|
||
r = delta * usage_factor.usage_factor | ||
logger.info("RWMS: adjust R for provider %s: %.3f -> %.3f", |
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.
Silly question but what's "RWMS"? Weighted RMS perhaps?
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.
@kubkon no idea, as you may see, this logging line was just copied from the other place
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.
I believe it's more of RequestorWasmMarketStrategy
than whatever else though, @kubkon
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.
Indeed, RWMS
stands for RequestorWasmMarketStrategy
. We use this abbreviation in log messages to make them shorter, but perhaps this abbreviation renders them less readable.
import datetime as dt | ||
import peewee as pw | ||
|
||
SCHEMA_VERSION = 40 |
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.
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.
@zakaprov yeah, I noticed ... I find our migration system horribly broken in that regard... migration numbering (as opposed to their contents) should NOT be something you have to take into account when resolving merge conflicts... :/
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.
SCHEMA_VERSION
can be dropped altogether. Filenames decide the order that migrations are performed in.
If you believe that numbering is horribly broken please propose an alternative solution.
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.
@mfranciszkiewicz numbering itself is not the issue ... conflict resolution of those numbered migrations is the issue... it's okay for the numbering to determine the order but the existence of two migrations that share the same number should not be an issue. and as long as those migrations don't modify the same model, they should be able to co-exist...
good example could be Django's south
(later just renamed to "django migrations") which handles such cases gracefully... though, of course, it being a django-specific module, it cannot/should not be used in a project like ours ...
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.
@zakaprov lost it ;)
@mbenke some tests added ... |
- the need to explicitly .save() peewee factory instances + tests for WASM marketplace
bfaf357
to
d4ead7f
Compare
Codecov Report
@@ Coverage Diff @@
## develop #4802 +/- ##
===========================================
- Coverage 89.42% 89.33% -0.09%
===========================================
Files 226 216 -10
Lines 20540 20126 -414
===========================================
- Hits 18367 17980 -387
+ Misses 2173 2146 -27 |
closes GR-178