Dev Feed

Did this get fixed then? Comment in Aug 2022 says it was scheduled for upcoming 4.x beta, but we're now on version 5. It's marked as `Low Priority`, and isn't closed, so I'm guessing it still doesn't work as expected?

<!-- Please search existing issues to avoid creating duplicates. --> <!-- Please fill out ALL ITEMS in the bug report. We simply can't fix bugs if we don't have all the information --> - Sequel Ace Version (including build number): 5.3.0 (20102) - Sequel Ace Source (App Store/GitHub/Homebrew): Homebrew - macOS Version: 26.5.2 (25F84) - Processor Type (Intel/Apple): Apple - MySQL Version: 8.0.39 - macOS Localization: GB-UK **Is Issue Present in [Latest Beta](https://github.com/Sequel-Ace/Sequel-Ace/releases)?** <!-- Please try the [latest beta](https://github.com/Sequel-Ace/Sequel-Ace/releases). If the latest beta works, we've fixed the issue already and will get the fix out soon. There's no need to open a new issue for a bug already fixed in the latest beta. --> No mention of this bug fixed in the pre-release notes. **Description** When attempting to delete a column via the GUI I was presented with the macOS spinning circle of doom. The app became unresponsive, and then crashed. The column was still being dropped in the background when I looked at the showprocess list after re-loading Sequel Ace. The detail here is that this table had an expensive FULLTEXT index on a large text column, on a 5 million row data set. This index forces a COPY TABLE command in order to drop a column. This means dropping a column is a long-running process. **Steps To Reproduce** 1. Create a table that will mean dropping a column does not run instantly. 2. For my table, the runtime was about 40 minutes 3. Drop a column on a database 4. Notice that the macOS spinner of doom is presented after a small number of seconds (3/4) **Expected Behaviour** <!-- A clear and concise description of what you expected to happen. --> The app should not crash if the drop column command is taking a long time. The app should indicate that the drop is taking a long time, by way of some responsive mechanism. **Related Issues** <!-- Please search [Issues on GitHub](https://github.com/Sequel-Ace/Sequel-Ace/issues?q=is%3Aissue), including Closed Issues, for the bug. If the bug has been fixed and is pending release, there may already be a closed issue for it. If an existing report of your issue already exists, please don't open a new issue and refer to the existing issue. --> **Additional Context** <!-- Add any other context about the problem here. --> <!-- Please ATTACH any SCREENSHOTS AND CRASH LOGS that might help investigating and addressing the issue. --> <!-- Please please please attach crash logs (as zip files if needed) and don't paste the content of the crash itself, it's much easier for us to work with files than massive text blocks --> Not something you really want to do that often in a GUI given this kind of DDL change should be handed by migrations, but I was trying to get a feel of how long this took on a test database before writing a codified migration.

Wrong repo

https://sequelpro.com is down people⌛ I searched around for some mirrors for the "latest" Nightly Build but couldn't find any. Thankfully I just found that this exists: https://github.com/Sequel-Ace/Sequel-Ace I thought I'd put this issue here as another reference that people should be moving to Sequel Ace. _For what it's worth I asked AI for alternatives, and it didn't recommend Sequel Ace, despite being the closest living ancestor._ <img width="878" height="432" alt="Image" src="https://github.com/user-attachments/assets/ecd12278-b5a6-4bd0-8da5-f6b59ba84d39" />

@tgriesser we've actually implemented something like this at kwiff Our motivation was for local integration tests where we found our spin-up phase running full migrations, and it just ate time out of our test suite. cc @tomasniculae

@sunsheeppoplar you around to fix the conflict?

PullRequestReviewEvent

I agree. Feels like an obvious roll-in to `master` on the next release as the new link also works for me.

A step towards helping with these: https://github.com/knex/knex/issues/4678 https://github.com/knex/knex/issues/5818 https://github.com/knex/knex/issues/1596

PullRequestReviewEvent

```suggestion This is because MySQL uses an `Implicit Commit` for many schema related commands. ```

We could advise here: `For this reason, as best practice, every DDL change should be isolated to it's own file for clean "complete status" and rollback strategy.`

If there are any users of this package who would like to help with maintaining it I would be grateful to hear from you. I do my best, but time is limited. In particular anyone interested in building out tests for CI/CD would be very useful.