{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":14189401,"defaultBranch":"master","name":"django-evolution","ownerLogin":"beanbaginc","currentUserCanPush":false,"isFork":false,"isEmpty":false,"createdAt":"2013-11-07T00:04:43.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/3821199?v=4","public":true,"private":false,"isOrgOwned":true},"refInfo":{"name":"","listCacheKey":"v0:1697412383.0","currentOid":""},"activityList":{"items":[{"before":"8e479865deb1f4dc3473d48fa368fcdfa9802695","after":"ff37ac76722ef56a5dacd6251c0acc659cded765","ref":"refs/heads/master","pushedAt":"2024-04-10T16:06:54.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"davidt","name":"David Trowbridge","path":"/davidt","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2240?s=80&v=4"},"commit":{"message":"Merge branch 'release-2.x'","shortMessageHtmlLink":"Merge branch 'release-2.x'"}},{"before":"0fae07cfc06b885a3f2bfa7d1dfdc51fb62cfc2a","after":"fc2b9a539077699eaa2dd0a88de1ee440d05ccaa","ref":"refs/heads/release-2.x","pushedAt":"2024-04-10T16:06:41.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"davidt","name":"David Trowbridge","path":"/davidt","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2240?s=80&v=4"},"commit":{"message":"Add configuration for renamed field module paths.\n\nIn some cases, field classes may be renamed or moved to different\nmodules. django-evolution had some one-off logic to handle this for when\ndjango itself moved all the fields from `django.db.models.fields` to\n`django.db.models`, but there was nothing available to consumers of the\nlibrary to do the same.\n\nWe recently ran into a problem where we decided to remove a dependency\non a third-party field, replacing it with a compatible home-grown\nimplementation. This worked fine, except django-evolution would fail to\nload the signature because the old module didn't exist. This change adds\na new mapping to the django-evolution configuration,\n`RENAMED_FIELD_TYPES`, which allows a project to define their own\nrenames.\n\nTesting Done:\n- Used this in conjunction with code that set\n  `DJANGO_EVOLUTION['RENAMED_FIELD_TYPES']` to a mapping from our old\n  third-party library to our new implementation, and saw that\n  django-evolution management commands and `Evolver` calls worked\n  correctly.\n- Ran unit tests.\n\nReviewed at https://reviews.reviewboard.org/r/13698/","shortMessageHtmlLink":"Add configuration for renamed field module paths."}},{"before":"e760c59cb4369015aea4d5e1ab478d670aa353ee","after":"8e479865deb1f4dc3473d48fa368fcdfa9802695","ref":"refs/heads/master","pushedAt":"2023-10-15T23:26:44.000Z","pushType":"push","commitsCount":4,"pusher":{"login":"chipx86","name":"Christian Hammond","path":"/chipx86","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4063?s=80&v=4"},"commit":{"message":"Merge branch 'release-2.x'","shortMessageHtmlLink":"Merge branch 'release-2.x'"}},{"before":"80fccabf20a17e13d3aa02b159437008241977c4","after":"0fae07cfc06b885a3f2bfa7d1dfdc51fb62cfc2a","ref":"refs/heads/release-2.x","pushedAt":"2023-10-15T23:26:21.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"chipx86","name":"Christian Hammond","path":"/chipx86","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4063?s=80&v=4"},"commit":{"message":"Bump to 2.3.1 dev.","shortMessageHtmlLink":"Bump to 2.3.1 dev."}},{"before":"bb04d9b42616923a2abc3128c556a34b5bc3aed7","after":"80fccabf20a17e13d3aa02b159437008241977c4","ref":"refs/heads/release-2.x","pushedAt":"2023-10-15T23:23:44.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"chipx86","name":"Christian Hammond","path":"/chipx86","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4063?s=80&v=4"},"commit":{"message":"Add docs and update release notes for db_table_comment.\n\nThis updates the `ChangeMeta` docs to document the new\n`db_table_comment` support, and also adds this to the release notes.\n\nTesting Done:\nBuilt the docs and checked through the new additions.\n\nReviewed at https://reviews.reviewboard.org/r/13347/","shortMessageHtmlLink":"Add docs and update release notes for db_table_comment."}},{"before":"756eedeacc41f77111a557fc13dee559cb94f433","after":"e760c59cb4369015aea4d5e1ab478d670aa353ee","ref":"refs/heads/master","pushedAt":"2023-10-15T20:54:29.000Z","pushType":"push","commitsCount":10,"pusher":{"login":"chipx86","name":"Christian Hammond","path":"/chipx86","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4063?s=80&v=4"},"commit":{"message":"Merge branch 'release-2.x'","shortMessageHtmlLink":"Merge branch 'release-2.x'"}},{"before":"deef61efe8c7497f3f3073f4000c3984f77ff557","after":"bb04d9b42616923a2abc3128c556a34b5bc3aed7","ref":"refs/heads/release-2.x","pushedAt":"2023-10-15T20:35:16.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"chipx86","name":"Christian Hammond","path":"/chipx86","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4063?s=80&v=4"},"commit":{"message":"Fix the formatting of SQL test data for Postgres on Django 1.6.\n\nDjango 1.6's generated SQL output for Postgres CREATE TABLE operations\ndiffers greatly from that of future versions of Django, and for other\ntypes of operations. Instead of a single string for a whole CREATE\nTABLE, we get one line of each in the generated SQL array.\n\nBecause of this difference, my update to add `pk_field_def` failed,\nsince I added it to the end of a CREATE TABLE block and not to the line\nthat needed it.\n\nThis is a trivial change, updating just a few statements.","shortMessageHtmlLink":"Fix the formatting of SQL test data for Postgres on Django 1.6."}},{"before":"744905fb523803c0f766ab5eceecadfcb90b01cd","after":"deef61efe8c7497f3f3073f4000c3984f77ff557","ref":"refs/heads/release-2.x","pushedAt":"2023-10-15T20:09:07.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"chipx86","name":"Christian Hammond","path":"/chipx86","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4063?s=80&v=4"},"commit":{"message":"Conditionalize Meta.db_table_comment in tests based on Django support.\n\nThe previous change to support evolving `db_table_comment` broke on\nDjango 1.11 and older, due to this being an unsupported attribute in\n`Meta` and Django being particularly strict.\n\nThis is a trivial change to conditionalize setting this in test data\nbased on our `supports_db_table_comments` flag.","shortMessageHtmlLink":"Conditionalize Meta.db_table_comment in tests based on Django support."}},{"before":"5b4ae8d445752e49a050201e808bd82fead5eb94","after":"744905fb523803c0f766ab5eceecadfcb90b01cd","ref":"refs/heads/release-2.x","pushedAt":"2023-10-15T19:58:53.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"chipx86","name":"Christian Hammond","path":"/chipx86","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4063?s=80&v=4"},"commit":{"message":"Add support for table comment evolutions in Django 4.2+.\n\nDjango 4.2 introduced table comments. These are comments that are part\nof the table schema, describing a table, and are supported in MySQL 8+\nand Postgres 12+ (the minimum versions that Django 4.2 supports), but\nnot SQLite.\n\nThis supports signature storage of table comments and evolutions via\n`ChangeMeta`.\n\nThis functionality is required for Django 4.2 support, as this is\nintrospected on our mock models, and we don't want to risk storing empty\nvalues or misleading the backend. Fortunately, as we can piggy-back on\n`SchemaEditor`, support is easy to add and maintain going forward.\n\nTesting Done:\nRan unit tests for SQLite, Postgres, and MySQL on a range of database\nversions on Python 3.11 and 3.12, Django 3.2-4.2, which should provide\nsufficient coverage for this feature.\n\nReviewed at https://reviews.reviewboard.org/r/13344/","shortMessageHtmlLink":"Add support for table comment evolutions in Django 4.2+."}},{"before":"c499c083dbac4fea489a0044889e9243f8fe3f8b","after":"5b4ae8d445752e49a050201e808bd82fead5eb94","ref":"refs/heads/release-2.x","pushedAt":"2023-06-20T01:23:04.918Z","pushType":"push","commitsCount":2,"pusher":{"login":"chipx86","name":"Christian Hammond","path":"/chipx86","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4063?s=80&v=4"},"commit":{"message":"Add release notes and update compatibility docs for Django Evolution 2.3.\n\nDjango Evolution 2.3 is a small feature release that adds some debug\nlogging, some new advanced management commands for working with\nevolution history, and explicit support for Python 3.12 and Django 4.2.\n\nDocumentation has been updated to note the new version compatibility.\n\nTesting Done:\nBuilt the release notes. Checked for any build errors or spelling errors\nor bad links.\n\nReviewed at https://reviews.reviewboard.org/r/13110/","shortMessageHtmlLink":"Add release notes and update compatibility docs for Django Evolution …"}},{"before":"8039ad16a0219dd358984b996500ca0a210bebf4","after":"c499c083dbac4fea489a0044889e9243f8fe3f8b","ref":"refs/heads/release-2.x","pushedAt":"2023-06-03T01:45:59.092Z","pushType":"push","commitsCount":3,"pusher":{"login":"chipx86","name":"Christian Hammond","path":"/chipx86","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4063?s=80&v=4"},"commit":{"message":"Add useful debug logging for evolutions.\n\nThis introduces some standardized debug logging for evolutions, which\nprovides information that can be helpful when debugging evolution\nfailures.\n\nThis is on the debug level, so people won't see it by default.\n\nThere's also a fix for serializing information on callable values, which\navoids a crash during debug logging.\n\nTesting Done:\nPerformed some evolutions, and inspected the output as part of a database\nevolution diagnosis.\n\nUnit tests pass.\n\nReviewed at https://reviews.reviewboard.org/r/13093/","shortMessageHtmlLink":"Add useful debug logging for evolutions."}}],"hasNextPage":false,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAELT39HgA","startCursor":null,"endCursor":null}},"title":"Activity · beanbaginc/django-evolution"}