3 ms·
There was a wave of popularity in 2017 as well. I used to work on it full time back then, and enjoyed it a lot. The SQLProvider [0] and other type providers lik
by pininja 5y ago
There was a wave of popularity in 2017 as well. I used to work on it full time back then, and enjoyed it a lot. The SQLProvider [0] and other type providers like it are super impressive!
[0] https://fsprojects.github.io/SQLProvider/ https://fsprojects.github.io/SQLProvider/
- xupybd 5y agoI've done a few little projects with the SQL provider. I worry about maintainability. You can't compile if the schema changes without you knowing about it. I haven't run into any real problems as a result but it does make me nervous.
- mumblemumble 5y ago> You can't compile if the schema changes without you knowing about it. There are those who would argue that making an incompatibility between the database schema and the code that interacts with it a compile-time error instead of a run-time error is a huge win for software quality. I suppose there are situations where you simply can't have access to a database that mimics the structure of the production database during development. In which case, the SQL provider is definitely not the right tool for the job. But it might be worth looking into ways to change how you do things in order to make it the right tool for the job. A SQL database with an unpredictable schema makes me much more nervous.
- pharmakom 5y agoYou can save a snapshot of the schema into your repo.
- piaste 5y ago> You can't compile if the schema changes without you knowing about it That's why you don't normally compile against the production database. You version control the database schema and use it to create a local database to compile against. This way you can also test potential future migrations using branches. Compiling against the production database should be done separately, as a kind of free integration test (usually in CI).