Re: Re[8]: [sqlite] Accessing Database on Network

2005-08-09 Thread Mrs. Brisby
On Wed, 2005-08-10 at 00:30 +0200, djm wrote:
> Hello,
> 
> Henry> No. It might be on your particular systems, but we cannot make
> Henry> a general case. It is possible that it will always be safe on
> Henry> (for example) Windows 2000, while not safe on NT or XP! It
> Henry> depends on how the OS handles caching. They are supposed to
> Henry> check on each file access to see if the file changed, but
> Henry> networks are slow, so they might not. Thus you could start
> Henry> reading data that is in the cache, which is out of date.
> 
> My understanding, after all of your helpful comments,  currently is:
> 
> Simultaneous reading of a server file by different clients is safe, as
> long as the file doesnt get changed at all (at least in a time scale
> where the Client Os could cache it).

Remove your parenthesized exception and this is correct.


>  Updaing the file might cause
> problems becuase of caching on the Client Os side, no matter how
> cleanly and isolated this update was done (eg all clients off, and
> update on server machine). (Im not sure I fully understand what terms
> like "atomic and "durable" mean in this context but I presume Ive
> gotten the jist?)

This is correct.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cossdk/html/857d145c-710d-4097-8ed6-df11e8d52228.asp

You should really know what atomic and durable mean.



> The same applies to sqlite accesses since it just uses regular files.
> And when you only querying the database (not changing the data), you
> are just reading the database file .. ie sqlite doesnt do anything
> which would break the clients only reading condition.
> 
> Am I right so far?

Almost. You make a distinction between Client and Server and I don't
think you know who they are.

It's helpful to understand that the server cannot update files. Ever.
Only clients can update files. The server coordinates these updates. In
reality, in many cases, the server coordinates fine. In others, it fails
miserably.

The file cannot be updated by anything but a server. If you rename() it
on the "local machine" you are doing that rename as a client- at least
as far as all of these statements about networked/distributed
filesystems being unsafe are.


> >> In my opinion system time stamps etc are not a reliable means of
> >> comparing 2 files. Many things can change the timestamp of a file,
> >> without changing the contents, and one (server) os/filesystem can
> >> report a different file size to another (local) for the same file
> >> (contents). As I said already, I think having a version number
> >> embedded in the databse itself is much more relible.
> 
> Mrs.> Wrong. The sqlite database is binary. Any size check is going to
> Mrs.> be in 8-bit bytes and will always be the same- except for
> Mrs.> platforms that SQLite doesn't run on- any comparison with a
> Mrs.> system that doesn't have 8-bit bytes will have to be aware of
> Mrs.> that fact.
> 
> The size of a file depends for example on the cluster size of the
> underlying partition. And regardless is of little value in comparing
> two files; the same file size/name doesnt mean two files are
> identical.

The size of a file does not depend on the cluster size of the underlying
partition. That's how much SPACE the file takes up.

Whether or not your filesystem records the size of a file isn't
important. The concept of file size exists, and it has nothing to do
with clusters or blocks or extents.

As a matter of fact, almost all filesystems record the correct file
size.

CP/M is a notable filesystem that does not. AFAIK, SQLite won't run in
CP/M so this is moot.


The test is not to determine whether or not the files are identical, but
if one has been changed. This method will certainly download files when
they haven't been changed (although it's unlikely). This unusual case
wastes some bandwidth. In contrast to downloading it all the time, where
you always waste bandwidth.


> Mrs.> You still haven't said what platform you're developing for.
> 
> Windown in particular, but also others.

http://support.microsoft.com/kb/q163401/
http://support.microsoft.com/kb/q148367/
http://www.winguides.com/registry/display.php/1295/

WARNING: in this mode, SQLite will be much much slower than your earlier
tests would indicate.


others networked filesystems have other semantics. I'm not going to even
try to list them all.



> Mrs.> djm: You still haven't told us exactly what you're using.
> 
> Im currently using C++ (Qt) but also plan to use php with sqlite for
> other projjects. In either cases the app should be cross platform.

If you're looking for cross-platform you need to select protocols that
have well defined semantics. HTTP sounds like a good bet. Full file copy
sounds like a better one.



Re[8]: [sqlite] Accessing Database on Network

2005-08-09 Thread djm
Hello,

Henry> No. It might be on your particular systems, but we cannot make
Henry> a general case. It is possible that it will always be safe on
Henry> (for example) Windows 2000, while not safe on NT or XP! It
Henry> depends on how the OS handles caching. They are supposed to
Henry> check on each file access to see if the file changed, but
Henry> networks are slow, so they might not. Thus you could start
Henry> reading data that is in the cache, which is out of date.

My understanding, after all of your helpful comments,  currently is:

Simultaneous reading of a server file by different clients is safe, as
long as the file doesnt get changed at all (at least in a time scale
where the Client Os could cache it). Updaing the file might cause
problems becuase of caching on the Client Os side, no matter how
cleanly and isolated this update was done (eg all clients off, and
update on server machine). (Im not sure I fully understand what terms
like "atomic and "durable" mean in this context but I presume Ive
gotten the jist?)

The same applies to sqlite accesses since it just uses regular files.
And when you only querying the database (not changing the data), you
are just reading the database file .. ie sqlite doesnt do anything
which would break the clients only reading condition.

Am I right so far?

>> In my opinion system time stamps etc are not a reliable means of
>> comparing 2 files. Many things can change the timestamp of a file,
>> without changing the contents, and one (server) os/filesystem can
>> report a different file size to another (local) for the same file
>> (contents). As I said already, I think having a version number
>> embedded in the databse itself is much more relible.

Mrs.> Wrong. The sqlite database is binary. Any size check is going to
Mrs.> be in 8-bit bytes and will always be the same- except for
Mrs.> platforms that SQLite doesn't run on- any comparison with a
Mrs.> system that doesn't have 8-bit bytes will have to be aware of
Mrs.> that fact.

The size of a file depends for example on the cluster size of the
underlying partition. And regardless is of little value in comparing
two files; the same file size/name doesnt mean two files are
identical.


Mrs.> You still haven't said what platform you're developing for.

Windown in particular, but also others.

Mrs.> djm: You still haven't told us exactly what you're using.

Im currently using C++ (Qt) but also plan to use php with sqlite for
other projjects. In either cases the app should be cross platform.

Best regards,
 djmmailto:[EMAIL PROTECTED]