Pridėti galimybę atnaujinti backend metadata kol įjungtas serveris

[JustinasKen]

#113 Užduotis pridėjo InternalSQLManifest tipą, kurio visas principas buvo, kad veiktų dinamiškai, neperkraunant serverio. Šis funkcionalumas buvo panaudotas įgyvendinant #479 užduotį. Šioje užduotyje buvo susidurta su viena problema, kad atnaujinus duomenų struktūra yra sudėtinga atnaujinti backend metaduomenis, kaip PostgresSql, kuris saugoja engine, schema ir tables kintamuosius. Kad išspręsti šią problemą buvo sukurta reload_backend_metadata funkcija.

spinta/spinta/manifests/internal_sql/commands/backend.py

Lines 7 to 11 in 9d85e55

	@commands.reload_backend_metadata.register(Context, InternalSQLManifest, PostgreSQL)
	def reload_backend_metadata(context: Context, manifest: InternalSQLManifest, backend: PostgreSQL):
	backend.schema.clear()
	backend.tables = {}
	commands.prepare(context, backend, manifest, ignore_duplicate=True)

Problema, kad toks sprendimas nėra korektiškas, kadangi backend yra globalus objektas, kuris yra laikomas Store klasėje. Kaskarta darant naują užklausą yra perkuriamas backend, kas nėra gerai, nes smarkiai stabdo sistemą ir dėl to gali kilti kitos klaidos.

Yra keli galimi sprendimo variantai:

1. Daryti atskirus instances kiekvienam request.
   • Privalumai:
     • Lengvai ir greitai įgyvendinamas
   • Trūkumai:
     • Veikia tik su dinaminiais manifest.
     • Sudėtinga naudoti statinius ir dinaminius manifest vienu metu (statinių manifest backends neatsinaujintu, kas teoriškai neturėtų įtakoti, nes visais atvėjais, neturėtume gyvai atnaujinti statinių manifest lentų).
   • Sprendimas:
     Kaskartą darant užklausą nenaudoti store.backend, o sukurti jo naują, nepriklausomą kopiją ir naudoti ją. Tokiu būdu bus galima daryti betkokius pakeitimus ir tai neįtakotų dabartinių užklausų.
2. Naudoti globalų backend ir atnaujinti jį tik kai reikia.
   • Privalumai:
     • Galima naudoti statinius ir dinaminius manifest, kurie naudoja tą patį backend kartu.
     • backend visada yra su naujausiais metadata.
   • Trūkumai:
     • Sudėtinga įgyventi.
     • Reikia sukurti nemažai naujų pakeitimų, kad sistema sugebėtų gerai tai palaikyti.
   • Sprendimas:
     • Prie InternalSQLManifest pridėti _revision stulpelį, pagal kurį žinotume, ar buvo atlikti pasikeitimai.
     • Prie PostgreSql backend get_table pridėti papildomus patikrinimus, kurie kaskarta žiūri ar _revision sutampa, jei ne, turi iškviesti backend metadata atnaujinimus.
     • Kaskarta darant schemos migracijas, reikia sekti ir atnaujinti backend metadata, jei tas backend renka susijusia informacija.
     • Įdėti thread lock funkcionalumą, kad kol yra atnaujinamas backend negalėtų jį keisti kitos sistemos vietos.

Susiję

• Struktūros atnaujinimas Saugykloje katalogas#346