> what happens if you rollback a transaction that just updated
> an image file?
>
> for that matter, what happens if one transaction is using or
> even reading an image while another is updating it?
One thing I mentioned was about a point in time backup, not updating the image.
This would rollback the transaction on the backup server, not the live one.
I was also proposing to never update an image. Just generate a new file, you
got 64-bits worth of ids. If you need to rollback an update to image on the
live server, unlink() the file and rollback. If all is good, unlink the old
version.
andrew
Ragnar wrote:
On fös, 2007-01-05 at 15:49 -0500, Andrew Chernow wrote:
I 100% agree. Use the database as a lookup into the filesystem. Don't load the
database up with terabytes of non-searchable binary data? not sure how that
would help you?
>I mean, how do you handle integrity with data
> outside the database?
You don't, the file system handles integrity of the stored data. Although, one
must careful to avoid db and fs orphans. Meaning, a record with no
corresponding file or a file with no corresponging record. Always
write()/insert an image file to the system within a transaction, including
writing the image out to the fs. Make sure to unlink any paritally written
image files.
what happens if you rollback a transaction that just updated
an image file?
for that matter, what happens if one transaction is using or
even reading an image while another is updating it?
gnari
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your
message can get through to the mailing list cleanly
