Linee guida per l'implementazione di SQLite VFS con FOpen *

Question

Sto per implementare un VFS personalizzato (file system virtuale) per un dispositivo incorporato Netburner (non Windows) utilizzando FOpen, FRead, FWrite, FSeek e FClose. Sono rimasto sorpreso dal fatto che non sono riuscito a trovare una versione FOpen * del VFS disponibile. Lo renderebbe molto più portatile per i dispositivi incorporati.

ho trovato alcune informazioni sulla creazione del VFS per SQLite qui http://sqlite.org/c3ref/vfs.html ma le informazioni è molto dettagliata e ho un sacco di altre domande circa l'attuazione.

Ho qualche esempio di VFS nel codice sorgente SQLite per Win, OS2, Linux ma non hanno molti commenti, solo codice sorgente.

Potrei utilizzare le informazioni fornite nel link sopra e gli esempi per creare il mio VFS personalizzato ma sono sicuro che mi mancherebbe qualcosa se l'avessi fatto in quel modo.

Le mie domande sono:

• C'è più documentazione sulla SQLite VFS che mi manca? Forse una guida all'implementazione?
• Esiste una versione Fopen di VFS SQLite disponibile?
• Esiste un codice di test dell'unità disponibile per testare il mio VFS SQLite personalizzato una volta creato?
• Suggerimenti, commenti, esperienze con l'implementazione di VFS SQLite che si desidera condividere.

Answer 1

Avete notato che c'è un'ulteriore fonte di documentazione nel file di intestazione sqlite3.h? Inoltre, la ricerca del codice di Google è tua amica.

Non preoccuparti troppo delle cose mancanti, questo è ciò che la suite di test è per. Prova a indovinare lo scopo di ogni metodo dal nome, dalla documentazione e dalle implementazioni di esempio; andare per una prima bozza di implementazione; eseguire i test sulla piattaforma di destinazione; scorrere fino a quando la barra è verde. Da una lettura superficiale del documento interfaccia che lei ha citato, qui ci sono alcune ipotesi plausibili:

int (*xOpen)(sqlite3_vfs*, const char *zName, sqlite3_file*, 
       int flags, int *pOutFlags); 
    int (*xDelete)(sqlite3_vfs*, const char *zName, int syncDir); 
    int (*xAccess)(sqlite3_vfs*, const char *zName, int flags, int *pResOut); 
    int (*xFullPathname)(sqlite3_vfs*, const char *zName, int nOut, char *zOut); 

quelle sono le funzioni di gestione dei file-off-the-Mill Run. Noterai che xOpen() restituisce a sua volta una struttura sqlite3_file, che dispone di metodi di puntatore propri per la lettura e la scrittura.

void *(*xDlOpen)(sqlite3_vfs*, const char *zFilename); 
    void (*xDlError)(sqlite3_vfs*, int nByte, char *zErrMsg); 
    void (*(*xDlSym)(sqlite3_vfs*,void*, const char *zSymbol))(void); 
    void (*xDlClose)(sqlite3_vfs*, void*); 

Quelle sono le librerie condivise (vedere la pagina dlopen() uomo su Linux). In un ambiente embedded, probabilmente puoi lasciare questi non implementati (prova a impostarli su NULL).

int (*xRandomness)(sqlite3_vfs*, int nByte, char *zOut); 

Potrebbe essere necessario implementare un generatore di numeri casuali, se la libreria standard del sistema operativo non ne fornisce già uno. Suggerisco uno linear feedback register, che è piccolo ma buono.

int (*xSleep)(sqlite3_vfs*, int microseconds); 
    int (*xCurrentTime)(sqlite3_vfs*, double*); 
    int (*xCurrentTimeInt64)(sqlite3_vfs*, sqlite3_int64*); 

Queste sono le funzioni di gestione del tempo, da collegare con il sistema operativo.

int (*xGetLastError)(sqlite3_vfs*, int, char *); 

Si può ottenere via con il ritorno sempre 0 qui :-) Vedere unixGetLastError a os_unix.c (grazie Google Code Search!)

Buona fortuna!

Answer 2

Un'opzione consiste nell'utilizzare un VFS basato sulla memoria, quindi semplicemente scaricare la memoria in un file quando hai finito. Vedi: http://article.gmane.org/gmane.comp.db.sqlite.general/46450 per un VFS basato su memoria che supporta già la serializzazione/deserializzazione.

Lo svantaggio è che è necessario scrivere manualmente il file per farlo persistere. Se la tua applicazione muore improvvisamente, le modifiche intermedie al DB non verranno mantenute.