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

Update database engine postgresql #280

Merged

Conversation

UnknownPlatypus
Copy link
Contributor

Another small one 😄.

Fixes #268

)
for key, val in zip(node.keys, node.values)
)
and state.looks_like_settings_file()
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we can go a bit faster by putting this settings file check first (and caching it: #281 ), since it's the most likely check to exclude a node from consideration

Comment on lines 48 to 50
yield ast_start_offset(target_node), partial(
replace, src='"django.db.backends.postgresql"'
)
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

since #260, django-upgrade tries to match the quoting choice of existing code, so updating this to use a small token function to match the existing quote char

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah yeah right, I've seen in the blog post you merge that in the end. mb

settings,
filename="myapp/settings.py",
)

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should also test when DATABASES has two relevant backends, I'm inserting a test here

@@ -0,0 +1,52 @@
"""
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the name of the file was missing “t” 😉

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Woops 😅

Comment on lines 31 to 35
and isinstance(parents[-1], ast.Dict)
and isinstance((db_setting := parents[-2]), ast.Assign)
and isinstance(db_setting.targets[0], ast.Name)
and db_setting.targets[0].id == "DATABASES"
and len(db_setting.targets) == 1
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

length checks should be done before accessing list indexes, to avoid crashes where the list isn't the required length. I don't think it's possible to have a crash here, though:

  • parents[-1] will always exist, and if it's a Dict, parents[-2] will always exist, at least as the ast.Module
  • I don't think it's possible for an Assign to have 0 targets (would be weird)

But still worth putting the length checks first to embed the right pattern, plus they should be cheaper than the isinstance checks.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it's possible for an Assign to have 0 targets (would be weird)

That's the assumption I made and the reason why I delayed the len check but yeah I'm not sure it's faster anyway and it's less clear so let's keep your version.

parents[-1] will always exist, and if it's a Dict, parents[-2] will always exist, at least as the ast.Module

yeah exactly, but I agree it might be confusing. Better explicit than implicit and the performance cost wont matter anyway

@adamchainz
Copy link
Owner

One small concern I just had - this will break code like:

if settings.DATABASES["default"]["ENGINE"] == "django.db.backends.postgresql_psycopg2":
    ...

and there’s not really much we can do to discover that (could be looked at in arbitrary variables)

I think that’srather unlikely though, since the recommended way to check a DB vendor is:

from django.db import connection
if connection.vendor == "postgres":
    ...

WDYT?

@UnknownPlatypus
Copy link
Contributor Author

yeah it looks rather unlikely I agree.

Also the first few stack overflow question i found about that were generally recommandation the connection.vendor way.

Maybe you should ask the folks on twitter which one they would have used to get more feedback on that ?

I feel like the recommended way is maybe not that well documented so I expect most people to land on stack overflow if they want to know how to check the project database vendor.

@adamchainz
Copy link
Owner

Also the first few stack overflow question i found about that were generally recommandation the connection.vendor way.

Good research.

Maybe you should ask the folks on twitter which one they would have used to get more feedback on that ?

I think this is kinda niche, likely won't see many responses.

Anyway we trust users to still be adults. If they use django-upgrade to change this string they’re responsible for any downstream effects.

@adamchainz adamchainz enabled auto-merge (squash) October 29, 2022 17:39
@adamchainz adamchainz merged commit a9845c4 into adamchainz:main Oct 29, 2022
@UnknownPlatypus UnknownPlatypus deleted the update_database_engine_postgresql branch October 29, 2022 17:41
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.

Update settings.DATABASES backend path django.db.backends.postgresql_psycopg2
2 participants