Co się dzieje, gdy dostawcy typu zmieniają się w F #?

Question

Po obejrzeniu Channel 9's video na F # Type Providers, zastanawiam się nad zmianami w schemacie danych. Don dotknął tego trochę na końcu, ale szukam więcej szczegółów.

1. Demo sprawiało wrażenie, jakbyś naciskał "." aby sprawdzić, jakie dane są dla Ciebie dostępne. Po połączeniu z, powiedzmy, przestępczością w USA w 2008 roku, co się dzieje, gdy rozpowszechniasz swoją aplikację i zmiany schematu? Czy pojawiają się błędy typu środowiska wykonawczego? Czy to deweloper jest odpowiedzialny za obsługę tych błędów?

2. Co więcej, czy to powoduje, że odpowiedzialność w rękach dostawcy typu?

   Obecnie po pobraniu zestawu .NET wiadomo, że nigdy się nie zmieni, dopóki użytkownik (ręcznie lub za pośrednictwem usługi) nie zaktualizuje go jawnie. Błędy kompilacji od ewoluujących typów muszą zostać rozwiązane, ale zawsze możesz wstrzymać aktualizację, aż będziesz gotowy na zmianę. Z dostawcami typów, czy trzeba ostrożniej programować przeciwko nim?

Answer 1

Reagowanie na zmiany schematu leży w gestii dostawcy typu, ale tylko w momencie rozwoju. Po opracowaniu aplikacji zostanie ona skompilowana przy użyciu dostawcy typu i przy użyciu bieżącego schematu w momencie kompilacji.

Podczas korzystania z dostawcy typów z programu Visual Studio można monitorować zmiany schematu i powiadamiać IDE Visual Studio, że nastąpiła zmiana w schemacie. Napisałem przykład dostawcy kodu XML, który to robi, więc gdy zmienisz schemat (plik XML użyty jako przykład), natychmiast uzyskasz błędy w VS. Zrobiłem video demonstration of this (około 19:40).

Po skompilowaniu programu dostawca typów generuje kod, który powinien zostać użyty w skompilowanym formularzu (a dostawca typów nie jest używany w środowisku wykonawczym). Oznacza to, że jeśli schemat zmienia się w czasie wykonywania, nie można nic z tym zrobić (programista musi zareagować). Jeśli zmiana schematu jest kompatybilna wstecz (tzn. Dodaje nowe kolumny do tabeli bazy danych), program może nadal działać poprawnie.