Updates to support changes starting in pgAdmin 9.3 #4300
Conversation
tjmoore4
force-pushed
the
pgadmin-9.3-updates
branch
4 times, most recently
from
ed573dd to
c9283eb
Compare
Changes in the flags used by pgAdmin's setup.py for user managment start in pgAdmin 9.3. Issue: PGO-2686
Capture the an expected user warning for pgAdmin9.8 using python3.11 and log as an INFO message rather than an ERROR which short-circuits user creation and updating.
tjmoore4
force-pushed
the
pgadmin-9.3-updates
branch
from
c28c6f4 to
6e9abbb
Compare
cbandy
left a comment
cbandy
left a comment
There was a problem hiding this comment.
I only had time for a quick look so far.
| script := fmt.Sprintf(` | ||
| PGADMIN_DIR=%s | ||
| cd $PGADMIN_DIR && python3 -c "import config; print(config.APP_RELEASE)" | ||
| cd $PGADMIN_DIR && python3 -c "import config; print(config.APP_VERSION)" |
There was a problem hiding this comment.
🤔 It looks like the result of this is only used when reconciling users. Can we move this into the commands there?
📝 It looks like pgAdmin 8.4 and newer have a version module with just these constants.
There was a problem hiding this comment.
I'll look into whether moving the commands makes sense. My guess is that would probably be fine as a refactor.
There was a problem hiding this comment.
Updated. The previous functions been removed and one test added to account for the scenario that wasn't being tested.
| } | ||
|
|
||
| var olderThan9_3 bool | ||
| versionFloat, err := strconv.ParseFloat(pgadmin.Status.MinorVersion, 32) |
There was a problem hiding this comment.
why bitsize 32 here but 64 when we retrieve the number to put into the status?
There was a problem hiding this comment.
Short version: That can probably be a 64, I'll make that change.
Longer version: I originally used 32 because I was intending to store the value directly into the status as a float. However, that's counter-indicated due to issues in float implementation and a string value is recommended instead. When the conversion happens, that function allows for 32 to be set so that the result will be convertible to float32 without changing its value despite returning a type float64 and, at the time, I wanted to use float32 because float64 was overkill for a simple version value.
3 participants
Checklist:
Type of Changes:
What is the current behavior (link to any open issues here)?
What is the new behavior (if this is a feature change)?
Other Information: