-
Notifications
You must be signed in to change notification settings - Fork 648
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
Implement missing SQLite features #1578
Comments
Syntactic parsing and semantic binding of database dictionary items is tricky. Every engine handles it differently. I had brainstormed some ideas to make this work smoothly awhile ago, but never wrote about it publicly (I didn't want others stealing the ideas and using it in competing projects without credit, since that has happened in the past and been discouraging). The general idea is to be able to implement "continuations" in FluentMigrator, or some kind of system where you reify a generic Processor and ProcessorContext. Right now, FluentMigrator doesnt have a concept of a processor context in the way some threading frameworks like scala zio do. Unlocking such functionality would solve some seemingly orthogonal issues, like fully offline migration scripting. Some of those ideas are documented loosely in the ADR folder. You can put together a proposal at a high level and I can review it. |
In working on the PR #1585 I did attempt to look at this briefly, but I think the trickiest thing here is that realistically it's just gonna be error prone having any generic solution as the whole duplicating a table is fine in simple examples but as soon as you bring views, triggers, constraints into the mix, it becomes a chain reaction of necessary changes. The SQLite docs does suggest querying the |
This is great research. What should I prioritize giving feedback to you on first? I'm thinking of releasing a 4.0.0-beta.1 release to let people bang on the changes, once we square away some of these open threads. Thoughts? |
Whilst looking through the SQLlite generator it appears that many of the features are just throwing compatibility notifications and whilst many of these features aren't implemented directly, some of them at least can be achieved by creating a temporary table with the new changes, copying the data over and then removing the old table
Given this is the suggested approach to work around these limitations, would it be possible to implement these missing features in this way?
The text was updated successfully, but these errors were encountered: