-
Notifications
You must be signed in to change notification settings - Fork 510
Add attachment annotations, converted_from, as well as a couple other nice things #7108
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
Add attachment annotations, converted_from, as well as a couple other nice things #7108
Conversation
...tions/versions/20250925_1631_e4f49c197158_add_annotations_and_converted_from_id_collation.py
Outdated
Show resolved
Hide resolved
...tions/versions/20250925_1631_e4f49c197158_add_annotations_and_converted_from_id_collation.py
Outdated
Show resolved
Hide resolved
...tions/versions/20250925_1631_e4f49c197158_add_annotations_and_converted_from_id_collation.py
Outdated
Show resolved
Hide resolved
2af5c08 to
38c648c
Compare
1042d1b to
da77adf
Compare
ThiefMaster
left a comment
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.
LGTM, but I think it's best to (test and) merge it together w/ the plugin changes
| # remove PG* variables from environment, as they may cause the following commands to fail | ||
| for env_var in ('PGUSER', 'PGPASSWORD', 'PGHOST', 'PGPORT', 'PGDATABASE'): | ||
| os.environ.pop(env_var, None) |
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.
Would it make sense to discard any PG* env vars?
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 didn't want to be so dramatic, in case there is some legit use for some variable starting with PG. But I'm not sure.
Any particular reason why you would not merge this one first? Just afraid that it will become stale. |
|
Primarily in case anything is missing... but OTOH it looks pretty complete. I guess you tested the collation stuff with weird characters (emoji, chinese and whatever) so it doesn't fail with an error in case of such content? |
I tried it with some special characters. Not necessarily Asian scripts. |
Also add case insensitive collation to the DB
Co-authored-by: Adrian <[email protected]>
a473fb1 to
611fad6
Compare
I don't like to just cascade there, even though this should only be used on test databases with no valuable data
This adds:
converted_from(and backrefconverted_to) to everyAttachment, which can of course beNone, and will help us keep track of attachments generated from other attachmentsannotationsfield/column (JSONB), useful to add metadata such as origin of the attachment (CloudConvert? CodiMD archiver? others?)case_insensitive, to the database, which does case-insensitive "predictable" sorting of names which takes into account also punctuation characters (contrary to Postgres' default). This is added only because I noticed that the sorting in attachments names was unintuitive