[Digikam-users] Digikam XMP schema ?
vh59 at gmx.de
Sun Feb 17 11:36:40 GMT 2013
that's a good idea. I will keep that in mind when upgrading to Suse 12.3 (what
is almost the most critical thing for the picture database)
Am Sonntag, 17. Februar 2013, 11:56:20 schrieb Jean-François Rabasse:
> Hi Volker,
> On Sun, 17 Feb 2013, Volker Henn wrote:
> > Hi, mysql is on the same machine.
> > With sqlite I obseverd that obviously (no guarantee) when a single change
> > is made, the whole database is written to hard disk. Then read again,
> > next change made, completely written again. This take lot of time, since
> > I organize my pictures in directories instead with tags, so I always
> > shift a lot of files. Mysql seems to have a better chache strategy.
> > Nevertheless there are problems with DK / mysql and the database user
> > must be root.
> Well, in that case you're right. Doing important reorganisations leads to
> important database activity. And SQLite3 is a light weight library without
> all caching ans requests journaling strategies real RDBMS have.
> In my previous comment, I intended mostly small actions (rating or tagging
> an image, etc.)
> For large operations (folders reorganisation, rereading metadata for many
> images, etc.) it's slow and I also happened to have problems, crashes or
> so. Not to be nervous, I took the habit to do that on a copy of database,
> and I/O access to the SQLite file can be enhanced when using a ramdisk.
> Linux supports that very well, so :
> - backup /.../digikam4.db to ... digikam3.db.backup
> - copy the file to ramdisk, /dev/shm/digikam4.db
> - start DK with option : --database-directory /dev/shm
> - work...
> - when all is ok, satisfying results, no corruptions, no crashes, copy
> the ramdisk file back to original place /.../digikam4.db
> (Before shutting down the computer:-)
> In case of problem, just forget, nothing is lost.
More information about the Digikam-users