[KPhotoAlbum] Large-scale DB merge

[Robert Krawitz]

On Sat, 20 May 2017 23:26:01 +0200, Johannes Zarl-Zierl wrote:
> On Freitag, 19. Mai 2017 23:20:38 CEST Robert Krawitz wrote:
>> I'm writing a perl script to do this.
>> 
>> Thus far I'm just doing the uncompressed format.  There may be
>> features I haven't taken into account yet; when I'm ready to send it
>> out people can comment.
>
> Sounds good.
>
>> I assume that the ordering of elements is arbitrary except within
>> images, where I'm sorting by <start date, file name>.
>
> Categories, member-groups and images (and blocklist) may appear in any order. 
>
> Within these elements, the order of sub-elements is usually
> non-random. E.g. the order of <image> tags within <images> denotes
> the order in which images are shown in the browser. Sorting this by
> date is a good idea for most users.
>
> Btw: maybe documentation/database-layout.md is of interest to you?

Thanks, I didn't know about that.

Image order definitely matters.  It doesn't appear to me that it
matters for anything else, though?

Right now I'm sorting images by starting date+filename.  This is from
when I was planning to allow adding files found in the merge file to
the original file, but I punted that because not all the metadata is
stored in the index.xml file, and because some files might not be
present on the target.  So I could either undo that sort and just use
the original order, or copy the entries from the merge file into the
target, and either allow EXIF data to be extracted or the nonexistent
files to be deleted by find files not on disk, in which case I
definitely would want to sort by date.

-- 
Robert Krawitz                                     <rlk at alum.mit.edu>

***  MIT Engineers   A Proud Tradition   http://mitathletics.com  ***
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton