I looked into that, and there seems to be one problem: How to expand the
size of a blob? A write won't expand it, according to (my understanding) of
the docs.

- Sherief

> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:sqlite-users-
> [EMAIL PROTECTED] On Behalf Of Dennis Cote
> Sent: Wednesday, July 23, 2008 10:22 AM
> To: General Discussion of SQLite Database
> Subject: Re: [sqlite] Transaction Files / SQLite?
> 
> Sherief N. Farouk wrote:
> >
> > Streams are parallel 'bags of bytes' of a file. As in, you can
> > open("x.txt"). or open("x.txt:SomeStream"). Or open
> > ("x.txt:SomeOtherStream"). When you copy x.txt, the streams get
> copied with
> > it (assuming, of course, the destination filesystem is NTFS).
> >
> > TxF is simple: modifications to the file aren't visible to other apps
> till
> > you commit, and the commit is atomic: other processes see the file as
> either
> > before or after the transaction. Basically, I don't want the contents
> > written while another process is doing a read().
> >
> > Hope that made things clearer.
> >
> 
> Yes, much clearer.
> 
> It seems to me that you could use blobs and the blob I/O support in
> SQLite to implement the streams of one (or more files) in a single
> database file. The transactions and built in locking in SQLite should
> provide all the functionality you need to provide atomic multiple
> reader
> single writer access to the database file.
> 
> Dennis Cote
> 
> 
> _______________________________________________
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to