[Digikam-users] Digikam XMP schema ?

[Volker Henn]

Hi  Jean-François
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)

Regards Volker

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.
> 
> Regards,
> Jean-François