Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Add dummy data for development#5

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
JelteF merged 21 commits intopostgres:masterfrompolkerty:dummy-data
Jan 26, 2025
Merged

Conversation

polkerty
Copy link
Contributor

@polkertypolkerty commentedJan 20, 2025
edited by JelteF
Loading

This PR implements a way to use dummy data for development in two ways:

  1. Dump a working dev database with Django'sdumpdata command. We dump theauth andcommitfest modules separately. This data can likewise be reloaded when starting from scratch with the correspondingloaddata commands (see the README.)
  2. Mocks the archives server, to allow users to search and add sample mailing threads to their patches.

There was an additional problem with this: The dumpdata django command would throw an infinite recursion error with our database schema. To solve this error this change also moves the ManyToMany relationship between MailThread and Patch from the MailThread side to Patch side.

JelteFand others added3 commitsJanuary 20, 2025 14:48
Previously we'd include the ID of the commitfest in the URL of thepatch. In9f12a5e we introduced a stable URL for patches that wouldredirect to the one for the latest commitfest. This starts to use thatURL as the valid only URL for a patch (with the previous URL redirectingto this one).The reasoning behind this is that the old approach resulted in Ndifferent URLs for each patch, which all showed the exact same patchinformation. The only difference between all these URLs would be thebreadcrumb at the top of the page.The only benefit of that approach is that if you're on an oldcommitfest, and click a link there, then the breadcrumb will bring youback to where you came from. Since people rarely have a reason to browseclosed commitfests, the that benefit seems pretty small. Especiallybecause people can just as well press their browser back button, in thatcase.The problems that these N links cause seem much more impactful to mostusers:1. If you click an old link to a cf entry (e.g. one from an email in the   archives), then the breadcrumb will contain some arbitrarily old   commitfest. It seems much more useful to have the breadcrumb show the   commitfest that the patch is currently active in (or got   committed/rejected in).2. If you arrive on such an old link you also won't be able to change   the status. Instead you'd get a message like: "The status of this   patch cannot be changed in this commitfest. You must modify it in the   one where it's open!". Which requires you to go to the latest page.3. Places that use the stable URLs require an extra round-trip to   actually get to the patch page.4. It's a bit confusing that old pages of a patch still get updated with   all the new information, i.e. why have all these pages if they   contain the exact same content.5. Problem 3 is generally also bad for Search Engine Optimization (SEO),   for now we don't care much about that though.Finally this also changes the links on the patch page itself for each ofthe commitfests that a patch has been part of. Those links were alreadyrather useless, since all they effectively did was change thebreadcrumb. But with this new commit, they wouldn't even do that anymore,and simply redirect to the current page. So now they start pointing tothe commitfest itself, which seems more useful behaviour anyway.
The bottom dropdowns on the patch page would expand downwards, requiringthe user to scroll down to see and click any of the buttons in the dropdown.With this change these are changed into "dropup" menus, so the expand upwards.
@JelteF
Copy link
Collaborator

Thank you for working on this. How did you generate this mock data? I'm assuming you have created some script? I think that script should be part of the PR, because we'll likely want to improve/update it in the future (e.g. when adding new tables/columns)

@polkertypolkerty changed the title[WIP] Dev databaseDev databaseJan 20, 2025
@polkerty
Copy link
ContributorAuthor

Thank you for working on this. How did you generate this mock data? I'm assuming you have created some script? I think that script should be part of the PR, because we'll likely want to improve/update it in the future (e.g. when adding new tables/columns)

@JelteF I updated the PR description and the README with more information! This is now a working POC, ie I can start from a fresh install and seed a working database now with these files.

@JelteF
Copy link
Collaborator

Thanks for the clear readme. How did you generate the archive_data.json file?

@polkerty
Copy link
ContributorAuthor

Thanks for the clear readme. How did you generate the archive_data.json file?

I took some data fromhttps://commitfest.postgresql.org/ajax/getThreads/?s=&a=1 and then made some manual modifications to anonymize it.

@JelteF
Copy link
Collaborator

I made a few changes, let me know what you think.

@JelteF
Copy link
Collaborator

To be clear it worked great! The main things I changed were:

  1. Including MailThread in the dump (required moving the ManyToMany around)
  2. Removing permissions from the dump (they are generated automatically)
  3. Adding a few more commitfests

@JelteF
Copy link
Collaborator

Also it seems like you haven't installedhttps://editorconfig.org/, because there were some trailing whitespaces in the README.

@polkerty
Copy link
ContributorAuthor

polkerty commentedJan 26, 2025 via email
edited
Loading

Wow, awesome! I’m especially impressed that you figured out the recursionerror. This all looks much better.

@polkerty
Copy link
ContributorAuthor

I updated the README and also verified that the dummy data update works in a clean install, thank you!

@JelteFJelteF changed the titleDev databaseDummy data for developmentJan 26, 2025
@JelteFJelteF changed the titleDummy data for developmentAdd dummy data for developmentJan 26, 2025
@JelteFJelteF merged commit4e86587 intopostgres:masterJan 26, 2025
JelteF added a commit that referenced this pull requestFeb 16, 2025
This PR implements a way to use dummy data for development in two ways:1. Dump a working dev database with Django's `dumpdata` command. We dumpthe `auth` and `commitfest` modules separately. This data can likewisebe reloaded when starting from scratch with the corresponding `loaddata`commands (see the README.)2. Mocks the archives server, to allow users to search and add samplemailing threads to their patches.To avoid an infinite recursion error this change also required movingthe ManyToMany relationship between MailThread and Patch from theMailThread to Patch side.---------Co-authored-by: Jelte Fennema-Nio <postgres@jeltef.nl>
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

2 participants
@polkerty@JelteF

[8]ページ先頭

©2009-2025 Movatter.jp