[KPhotoAlbum] Optimization of index.xml

[William Holland]

Hi all,

Having looked back into what I did in the past, this method works fine 
provided only *one* database is modified (it doesn't matter which), but yes, 
as you all point out, if there is a chance that one of the other databases is 
modified, (more specifically if one of the records is updated in both) then 
we run into a merge issue.

However I'm a fan of not re-inventing the wheel, so does anyone know of any 
already existing tools for 'merging' databases? Or is it genuinely a trivial 
task to write the code for the merge? I suspect my drive for lazyness (reuse) 
drives me to rather a lot of extra work sometimes ;)

Will
  --

On Monday 04 Sep 2006 20:58, Mark Eichin wrote:
> Also, most current database-level synchronization implementations
> really only support *live* cloning for scaling, not for offline
> propagation of changes.
>
> I'd suggest that the database level is the *worst* place to try to do
> it, because it has the least information available about the intent of
> the potentially conflicting users, and thus has the hardest time
> resolving conflicts.
>
> The fact that each picture has an immutable key (the md5sum) does
> help, it means you never "rename" anything, you just change field
> values...
>
> On 9/4/06, Shawn Willden <shawn-kimdaba at willden.org> wrote:
> > On Monday 04 September 2006 01:18, William Holland wrote:
> > > A while ago, I looked into synchronisation with mysql, and MySQL
> > > definitely supports synchronisation between two databases, so your best
> > > option is to look into the MySQL native Synchronisation, rather than
> > > writing a custom Kphotoalbum one.
> >
> > Perhaps that could be made to work, but I don't think it would be a good
> > fit. Master/slave synchronization is designed for a different application
> > and doesn't really support simultaneous changes to both databases. 
> > MySQL's clustered synchronization requires that all of the databases be
> > in constant communication and also limits you to in-memory databases. 
> > Further, using the native tools would limit synchronization to a single
> > database platform.  A purpose-built tool could easily synchronize across
> > any of the supported SQL engines.
> >
> > > There were some issues with multiple updates to the same
> > > record in both databases, but this was 5 years ago, so it's probably
> > > improved.
> >
> > I don't see how it could be, because this is a problem that doesn't have
> > an automated solution.  If the DB synchronization did attempt to handle
> > this, it would have to use some heuristic like "last change wins", but
> > that wouldn't necessarily work.  Conflicts must, IMO, be resolved by a
> > human.
> >
> > Your suggestion is worth exploring, certainly, but I don't have high
> > hopes that it will do the job.
> >
> > Thanks,
> >
> >         Shawn.
> >
> > _______________________________________________
> > KPhotoAlbum mailing list
> > KPhotoAlbum at kdab.net
> > http://mail.kdab.net/mailman/listinfo/kphotoalbum