Problemen nieuwe SQL database en app update
 

Sinds vannacht is mijn 2e app online. De app bevat een SQL database en leest hier zijn data uit. Nu heb ik met testen in simulater en op iphones al gemerkt dat zodra ik de database heb uigebreid, code hieraan heb aangepast (om de nieuwe data te lezen) en vervolgens op "Build and Run" druk, de applicatie niet opstart maar direct crasht. Dit komt omdat in de appdelegate de OUDE database in plaats van de NIEUWE database wordt doorzocht, waardoor er lege NSStrings geretourneert worden. Gevolg: de app crasht. Dit zelfde zal gebeuren wanneer ik een update via de App Store uit ga brengen met nieuwe data in de database. Blijkbaar zit er ergens een bug in Apple's software dat bij het updaten van een app die al geïnstalleerd is, de database niet vervangen wordt... (het werkt overigens wel als eerst de app verwijderd wordt, en vervolgens de update geïnstalleerd wordt).

Nu ben ik op zoek naar een oplossing voor dit probleem. Alleen heb ik geen idee hoe of wat. Iemand met hetzelfde probleem?

Dat heb ik ook gehad (RC-Timer Pro). Ik heb in iTunes en op de support-site vermeld dat je de App compleet van je iPhone moet verwijderen en dan weer moet syncen. Dan wordt de database wel verwijderd en crasht je App na een upgrade niet.

Tegen de gebruiker zeggen dat je de app eerst moet verwijderen is een slechte gebruikerservaring. Zeker als het een app betreft waarbij de gebruiker eigen gegevens heeft ingevoerd. Reken er dan maar op dat je veel 1 sterren beoordeling krijgt.

Je zou in je app tijdens het opstarten kunnen aangeven dat het de oude database file moet verwijderen en de nieuwe moet laden.

Overigens heeft Apple hier een oplossing voor: Core Data. Met Core Data kan je een SQLite3 database beheren op een object-georienteerde manier.
Als je aanpassingen maakt aan je database, dan geef je in je app aan dat het opzoek moet naar nieuwere databases. Core Data gaat dan zelf de oude SQL data store gebruiken om de database te openen en gebruikt de nieuwste om de gegevens te laden.
Op deze manier zullen je gebruikers niks door hebben en zullen ook hun gegevens bewaard blijven.
Verder is dit ook makkelijk tijdens debuggen, dat je niet telkens je app of SQLite file hoeft te verwijderen nadat je elke keer aanpassingen hebt gemaakt aan de database.

/offtopic/
Wat staat daar onderaan in RC-Timer Pro voor rare tekst (in spiegelbeeld) ?
/ontopic/

Prachtige app, hartelijk bedankt ;)

Dat is hier niet het geval. Niemand doet hier moeilijk over. De data in de database heeft geen lange 'houdbaarheid'.
Kijk, dat bedoel ik :)
Dat is sinds de iPhone 4. Moet ik nog effe fixen.

Ja dit is een probleem waar je wel vaker tegen aan zal lopen.
Als de database in de document directory staat wordt deze bij het update niet aangeraakt. Hij maakt nou een maal geen deel uit van de applicatie bundle.

Een oplossing die vaak gebruikt is om in de NSUserDefaults een database versie op te slaan.
Nu kan je in code controleren welke versie van de database er bij de gebruiker staat.
Ja kan dan nu een migratie script runnen om de database bij te werken.

Uh, dit is een review bij jouw app met een 1 ster beoordeling:
Je kan niet van de gebruiker verwachten dat ze de beschrijving lezen voordat ze updaten :)

Ahum, raken we niet een beetje offtopic hier?

Ik ga geen rekening houden met een enkele Duitser die de beschrijving niet leest en dan meteen een negatieve review plaatst.
Ik erken dat dit niet bij iedere Applicatie acceptabel is.

Wat is hier offtopic aan als ik vragen mag? Ik geef alleen een argument waarom ik het niet eens ben met jouw oplossing van dit probleem. Er zijn betere alternatieven dan dit, ongeacht om wat voor type app het gaat, vind ik.

Inderdaad, hou een versie nummer bij en als deze niet overeenkomt met de versie van de update, dan de oude database verwijderen en de nieuwe naar de documents folder kopieeren.

de gebruiker moet hier geen last van hebben. Crashen is een no-no.

Offtopic is dat je blijft ingaan op de keuze die ik anderhalf jaar geleden gemaakt heb. Dat weet ik nou wel. Daar schiet DJ14 niets mee op.
Ontopic is dat je een beter alternatief voorstelt, zoals jij en Wacko gedaan hebben.

Let wel: Ik twijfel of ik nu nog die zelfde keuze zou maken, maar het is een oplossing. Er zijn betere oplossingen, dat weet ik nu ook. Ook ik leer!

We laten DJ14 gewoon de keuze.

Crashen is NOOIT acceptabel. NOOIT.

Wie zegt dat ik dat acceptabel vind?

Dat impliceer je hiermee:

Heren, de groeten. Ik stop hier mee. Dit draadje ging over migratie van een SQLite database. Ik heb een mogelijke oplossing aangedragen, jullie hebben een veel betere en elegantere oplossing aangegeven. Daar kan de originele vragensteller prima mee uit de voeten.

Ik heb anderhalf jaar geleden de keuze gemaakt voor een minder elegante oplossing die in de praktijk voor de meeste gebruikers wel degelijk acceptabel was. Er zijn niet zo heel veel gebruikers van RC-Timer Pro, en de meeste kon ik via diverse forums prima bereiken en informeren. Als ik nu voor dezelfde keuze zou staan, dan zou ik het anders opgelost hebben. Dat is duidelijk.

Jullie mogen gerust blijven wubbe-bashen en beweren dat crashen niet acceptabel is en andere voor de hand liggende opmerkingen. Veel plezier er mee. Ga gerust je gang.

Maar daar gaat dit draadje al helemaal niet meer over...

offtopic: zow he relax mensen, ik zie nu pas alle reacties. mijn 1e reactie bij t zien hiervan: :eek:

ontopic: bedankt voor alle reacties !! :) Nu alle replies hieronder:

@Geno: jij zegt: "Je zou in je app tijdens het opstarten kunnen aangeven dat het de oude database file moet verwijderen en de nieuwe moet laden."

Hier heb ik ook al aan gedacht. Echter, wat me tegenhield om dit te implementeren:
1) het is nogal intensief/onnodig om bij elke launch database te verwijderen en nieuwe te pakken
2) waar haal ik de nieuwe database vandaan als ik de oude verwijder? De enige oplossing die ik hier dan zie is de lokale database dus verwijderen, en via een internet verbinding de nieuwe downloaden van een server. Nadeel: internet verbinding vereist, terwijl het een grote pre is dat de app juist voor zijn kernfunctionaliteit geen internetverbinding nodig heeft (het gaat om de app Outlet Finder).

Core data heb ik expres niet voor gekozen, omdat alleen een SQL database + direct uitlezen mij eenvoudiger leek, maar naarmate ik meer ervaring krijg zal ik me daar nog wel eens in verdiepen, tx voor de tip.

@Whacko: zie punt 2 hierboven

Het grootste probleem bij verwijderen is dus: in de app zit maar 1 database. Als je deze verwijdert, heb je niks meer.... Dus moet de nieuwe wel van internet worden geplukt.

@wubbe: niets van aantrekken, eigen keuzes maken, tis jouw app.

Je hebt nu een app uitgebracht met een oude database file. Je brengt een update uit met een nieuwe database file (zit in de nieuwe app, dus niet van internet afhalen). De eerste keer na het installeren van de update en opstarten checkt de app of er een oude database is, zo ja, dan migreert het naar de nieuwe database. Ik ben niet bekend met de migratie scripts van SQLite3, maar bij Core Data blijft de oude SQL file behouden en wordt hernoemd.

Thnx, nu snap ik het. De oude database zit in de documents directory, de nieuwe komt in de application bundle. Bij launch van app beide db's vergelijken en indien ze verschillen, oude verwijderen en nieuwe erin (kan evt ook met versienummer in kolom in database). Bedankt!

Ik zou niet de oude database verwijderen, maar dynamisch updaten met statements als:

ALTER TABLE x ADD COLUMN y;

Je kunt het versie nummer van de database ophalen met:

PRAGMA user_version;

en opslaan met:

PRAGMA user_version = x;

Dan heb je geen aparte tabel nodig om dit bij te houden.

Ligt er helemaal aan wat voor data er in de database staat.
Als je veel data moet gaan inserten kan dat erg lang duren en dan is vervangen soms makkelijker.
Natuurlijk moet je dan wel de gebruikers gegevens in de nieuwe database zetten.