[Digikam-users] Fwd: Sharing tags and rating between two machines

[Marcel Wiesweg]

> sava wrote:
> > OK, so nobody seems to have had a similar issue. I'll try to figure it
> > out myself, but could anybody tell me where Digikam stores the rating and
> > tags?
> >
> > Is there a way to import/preserve ratings and tags I created on the
> > laptop during the transfer to my desktop Digikam?
>
> The key problem with moving the data from sqlite to sqlite database is
> that the unique IDs aren't going to match up properly, nor will the
> paths (well, they might, but it's not a guarantee).
>
> One of the BKO entries I raised (and has been mentioned on this list)
> was to add a unique ID based on the checksum of the file, and use this
> as the unique identifier throughout all of the tables.  With that in
> place, it would be possible to generate a SQL dump from the laptop
> (initially, it'd have to be by hand) and import it on the desktop.
>
> I've looked at the code in an effort to find out how to add this ability
> - changing the SQL tables is easy (and Gilles, if they're not
> documented, I'll look at sending a patch to -devel, I work with SQL most
> days), I'm just having trouble finding where the albums are read in to
> get the files into the tables :)  

Partly it's done in the digikamalbums ioslave (kioslaves directory). This one 
is accessing the database independently.
It is triggered from scan() in dio.cpp, which is called by 
AlbumManager::slotDirty (KDirWatch's signal) or refresh(). The latter is 
called from various places, where only grep will tell you.

Then there is scanlib.cpp which is handling startup, but I have never read 
this code. At first glance it calls getOrCreateAlbumId, which is another 
place where albums are created.

I am struggling again and again to get an overview over all this, but at least 
it works quite well :-)

> Once I can find that, and I can find a 
> MD5/SHA1 algo (doesn't even have to be one of those, just something
> unique), I can look at calculating checksums when a new file is found,
> and track it in the tables.
>
> I don't know if the devs would accept the SQL and checksum generation
> patches for .9.0 - I probably wouldn't as a dev, simply because the
> checksum generation is not a trivial task.  It needs to be done in a
> lazy thread in the back of digikam, not up front when the program loads
> (can you imagine the processing time for a few thousand photos?).
>

IMO there is two reasons for not accepting this for 0.9.0, first is that 0.9 
is in mostly-bug-hunting-almost-no-new-features-unless-necessary phase,
second is, in my personal nonofficial and not discussed opinion if we make 
changes in this area, then as part of a broader change implementing other 
wishes such as file relations/links, better archiving support etc.

Marcel