Hur löser man problemet med olika databasversioner vid uppgr

[TomasL]

Hur löser man problemet med en gemensam databas för flera olika program.

Problemet:
Jag har flera olika programversioner (personaliteter) baserad på samma grundkod.
Jag har med en databas sparad i externt flash med alla inställningar och startup-värden, vilka till mycket stor del är gemensamt mellan de olika versionerna.
Jag har också en databas sparad i RAM med globala variabler gemensamma för alla system.

Mina problem är följande.
Om jag modifierar någonting i den externa databasen, så hamnar de redan sparade värdena i o-synk, vilket gör att jag i nuläget gör en komplett kall-boot och får mata in alla gamla inställningar på nytt (Dvs de som inte är default), det är rätt många, Något tusental totalt. Om jag inte gör detta får jag av naturliga skäl blåskärm, då index till arrayer mm hamnar fel.

Beträffande de globala variablerna så används de för att skicka data mellan de olika personaliteterna, och i dag använder jag den relativa adressen till variabeln. Förvisso är det förmodligen hyffsat enkelt att åtgärda, genom att indexera alla variabler (återigen något tusental).

Följaktligen, om jag ändrar någonting i någon av dessa två databaser, så måste samtliga enheter i systemet uppdateras till samma version.
Unik indexering av allt,, dock naturligtvis begränsat utrymme i program-minnet (som alltid när det gäller inbäddade system).
Jag vill naturligtvis kunna uppgradera utan att behöva göra en komplett radering.
Så teorisera, kom med idiotiska förslag, kom med användbara förslag osv.

[JimmyAndersson]

Vad vinner man om man gissar rätt på vilken hårdvara och mjukvara detta gäller?

Eller jag menar:
"eh nä, det går inte att lösa."

[TomasL]

Hårdvara spelar naturligtvis ingen roll, eftersom det är lite mer teori jag är ute efter, men visst det är PIC32, men det kunde lika väl vara en ARM, eller en X86 eller vad som helst.
Mjukvara, ja det är ju det, det handlar om, hur man bäst konstruerar den.

[Micke_s]

Man specar upp hur datan i ”databasen” ska se ut. Sedan skriver man kod som följer specen för läsa/skriva i den.

[TomasL]

Och när man behöver utöka den, lägga till saker i slutet funkar ju (om man kan komma på ett bra sätt att initiera), men om man behöver utöka i mitten?

[PeterH]

Man kanske kan speca några generella fält (antal efter gissat behov) som används för framtida behov, den gamla versionen frågar bara efter dom gamla "kända fälten" och den nya nyttjar dom gamla plus någon av dom generella... Man kan naturligtvis aldrig framtidssäkra helt om man inte ska ha en himla massa generella fält. Den nya koden kan ju innehålla en mappning som bara gäller för sin egen version, ex, fält1=antal, fält2=äpplen osv.?

[sodjan]

Vad är en "databas" här? I min värld är det en traditionell relationsdatabas med SQL gränssnitt.
Och i alla fall i den som jag jobbar med (och det borde gälla för vilken som helst) så är det
inget problem att t.ex. läggs till fält i tabeller, de gamla programmen fortsätter att fungera,
så vida de inte var byggda med "SELECT *...", men det gör man ju inte i produktion.

Vad är det för underlig databas som har en "mitt"?? I en normal databas så är ordningen
på fälten (d.v.s. hur de fysiskt lagras på disk) i princip odefinierad.

[Johanb]

Det kanske är något hemmapul typ länkad lista eller kolumnerna i en struct med känd storlek?

[TomasL]

En databas är väl en samling data ordnat på ett mer eller mindre strukturerat sätt.

I detta fallet är en databas, eftersom det handlar om inbyggda system, en eller flera strukturer i varierande storlekar, lagrat i flash-minne. där accessen per natur sker med den fysiska adressen.
Eftersom man är begränsad i programminne mm så kan man naturligtvis inte skruva in en databasmotor, som SQL eller liknande, ej heller ett riktigt filsystem.

[Johanb]

Ahh, det hade varit bra att veta från början

Beroende på om utrymme finnas kan du ha en rutin som gör en rebuild på databasen när en ändring sker,
den borde klara sig med gamla och nya schemat.
Det blir mycket läsa och skriva men du kommer att få en "ren" databas efter.

[TomasL]

Nja, har funderat på det, men, man måste då läsa varje variabel individuellt, för att sedan skriva ned dem individuellt. Blir typ 4000 rader c-kod av det.

[JimmyAndersson]

Hårdvara spelar naturligtvis ingen roll, eftersom det är lite mer teori jag är ute efter, men visst det är PIC32, men det kunde lika väl vara en ARM, eller en X86 eller vad som helst.
Mjukvara, ja det är ju det, det handlar om, hur man bäst konstruerar den.

Bara så att jag förstår: I första inlägget skrev du:

Jag har flera olika programversioner (personaliteter) baserad på samma grundkod.
Jag har med en databas sparad i externt flash med alla inställningar och startup-värden, vilka till mycket stor del är gemensamt mellan de olika versionerna.
Jag har också en databas sparad i RAM med globala variabler gemensamma för alla system.

Men det har du alltså inte?
Utan du vill alltså komma på en struktur som gör att du sedan kan lösa problem med olika versioner av den strukturen?

Isåfall är jag vilse. (Annars hade jag tänkt föreslå en variant av det som Sodjan skrev.)

[sodjan]

OK, då har vi alltså ingen "databas", bara en samling strukturerade applikationsdata.
Tja, det är väl bra att koordinera gemensamma data till applikationerna som vanligt.
Alla programversioner som körs samtidigt mot samma globala data måste ju så
klart vara kompatibla. Jag tror att jag förstår frågan men ser ingen enkel lösning.
Man kan ju lägga till en separat symboltabell med "namn"->"adress" par, men då
tillkommer en symbol lookup vid varje access av en variabel. Jag antar att du idag
har en fast tabell som länkas in i varje applikation så att den har adressen direkt.
Om den tabellen ändras så måste ju alla applikationer som använder den byggas om.

[TomasL]

Sodjan, rätt så.

[sodjan]

Man kan, med lite disciplin, ha en tabell där man enbart lägger till på slutet
och sen enbart lägger till nya data på tidigare oanvända/högre adresser.
Den kan då användas av nya applikationer och de gamla som enbart
använder de gamla variablerna, kan fortsätta fungera som tidigare.

Däremot blir det så klart en konflikt om man måste ändra storlek eller
datatyp på en gammal variabel, finns nog ingen genväg runt det.
Eller om man vill ha en ny variabel tillsammans med de gamla som
hör till samma grupp av variabler...