[Digikam-devel] Update query fails

[Swati Lodha]

I understand this now. Thank you for clarification.

So as it mentioned around coredb.cpp:549

549  // We need to work around the table constraint, no we want to delete
> older stale albums with
> 550  // the same relativePath, and adjust relativePaths depending on
> albumRoot.


I think that this needs to be done?

Regards
ᐧ

On Wed, Jun 1, 2016 at 2:28 PM, Marcel Wiesweg <marcel.wiesweg at gmx.de>
wrote:

> Have a look at the (rather complex) CollectionScanner.
>
> The problem is the nature of our scan, which will always run in all kinds
> of
> race conditions with the file system.
>
> When a folder is moved, we may notice that it is removed at the previous
> location. Later, we see it appear at the new location. It would be
> unfortunate
> to have completely deleted all album metadata in the meantime. Therefore,
> it
> is made a stale album, which can be resurrected later if a new place can be
> identified.
>
> This is done in a similar way for images. Here, we can identify them by
> content, so the storage of "removed" images is even more extensively done.
>
>
>
> > This query is executed in core/libs/database/coredb.cpp:576 in the
> function
> > to create stale Albums, that is why the albumRoot has been set to 0.
> >
> > I would like to ask why is there a need to create the stale Albums?
> >
> > Regards
> > ᐧ
> >
> > On Wed, Jun 1, 2016 at 1:19 AM, Marcel Wiesweg <marcel.wiesweg at gmx.de>
> >
> > wrote:
> > > Please check the context where it is called, but I am quite sure that
> > > there is
> > > a special meaning in setting album root to 0.
> > > I'm sure there is a similar case with deleted images where album is
> set to
> > > 0,
> > > but the entry is preserved in case the image reappears at a different
> > > place
> > > (moving files where the removal is noticed first)
> > >
> > > Marcel
> > >
> > > > Hello.
> > > >
> > > > I was facing this error from past few days:
> > > >
> > > > MariaDB [digikam]> update Albums set albumRoot=0 where id=10;
> > > >
> > > > > ERROR 1452 (23000): Cannot add or update a child row: a foreign key
> > > > > constraint fails (`digikam`.`Albums`, CONSTRAINT `Albums_AlbumRoot
> > > > > s` FOREIGN KEY (`albumRoot`) REFERENCES `AlbumRoots` (`id`) ON
> DELETE
> > > > > CASCADE ON UPDATE CASCADE)
> > > >
> > > > I figured out that as 'id' is AlbumRoots table is not 0. So
> 'albumRoot'
> > >
> > > in
> > >
> > > > Images table can't be set to 0. This is I think the possible reason
> for
> > >
> > > FK
> > >
> > > > constraint failing.
> > > >
> > > > I used this statement instead & it worked:
> > > >
> > > > MariaDB [digikam]> update Albums set albumRoot=1 where id=10;
> > > >
> > > > > Query OK, 0 rows affected (0.06 sec)
> > > > > Rows matched: 1  Changed: 0  Warnings: 0
> > > >
> > > > Please look into this.
> > > >
> > > > Regards
> > > > ᐧ
> > >
> > > _______________________________________________
> > > Digikam-devel mailing list
> > > Digikam-devel at kde.org
> > > https://mail.kde.org/mailman/listinfo/digikam-devel
>
> _______________________________________________
> Digikam-devel mailing list
> Digikam-devel at kde.org
> https://mail.kde.org/mailman/listinfo/digikam-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-devel/attachments/20160601/ea2c8638/attachment.html>