[KPhotoAlbum] Optimization of index.xml

Mark Eichin eichin at gmail.com
Mon Sep 4 20:58:50 BST 2006


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
>
>


-- 
_Mark_ <eichin at thok.org> <eichin at gmail.com>




More information about the Kphotoalbum mailing list