<div dir="ltr">I understand this now. Thank you for clarification.<div><br></div><div>So as it mentioned around <span style="font-size:12.8px">coredb.cpp:</span><span style="font-size:12.8px">549</span></div><div><br></div><div><div class="" style="font-size:13px;line-height:1.3;white-space:pre-wrap;color:rgb(0,0,0)"><blockquote style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex" class="gmail_quote"><span class=""><font face="monospace"> </font><font face="arial, helvetica, sans-serif"> 549</font></span><font face="arial, helvetica, sans-serif">     <span class="" style="color:rgb(128,0,0)">// We need to work around the table constraint, no we want to delete older stale albums with<br></span></font><font face="arial, helvetica, sans-serif"><span class="">  550</span>     </font><span class="" style="color:rgb(128,0,0)"><font face="arial, helvetica, sans-serif">// the same relativePath, and adjust relativePaths depending on albumRoot</font><font face="monospace">.</font></span></blockquote><div><br></div><div>I think that this needs to be done?</div><div><br></div><div>Regards </div></div></div></div><div hspace="streak-pt-mark" style="max-height:1px"><img style="width:0px;max-height:0px;overflow:hidden" src="https://mailfoogae.appspot.com/t?sender=ac3dhdGlsb2RoYTI3QGdtYWlsLmNvbQ%3D%3D&type=zerocontent&guid=02222bac-7414-4efd-b406-7d91d20cba50"><font color="#ffffff" size="1">ᐧ</font></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 1, 2016 at 2:28 PM, Marcel Wiesweg <span dir="ltr"><<a href="mailto:marcel.wiesweg@gmx.de" target="_blank">marcel.wiesweg@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Have a look at the (rather complex) CollectionScanner.<br>
<br>
The problem is the nature of our scan, which will always run in all kinds of<br>
race conditions with the file system.<br>
<br>
When a folder is moved, we may notice that it is removed at the previous<br>
location. Later, we see it appear at the new location. It would be unfortunate<br>
to have completely deleted all album metadata in the meantime. Therefore, it<br>
is made a stale album, which can be resurrected later if a new place can be<br>
identified.<br>
<br>
This is done in a similar way for images. Here, we can identify them by<br>
content, so the storage of "removed" images is even more extensively done.<br>
<span class="im HOEnZb"><br>
<br>
<br>
> This query is executed in core/libs/database/coredb.cpp:576 in the function<br>
> to create stale Albums, that is why the albumRoot has been set to 0.<br>
><br>
> I would like to ask why is there a need to create the stale Albums?<br>
><br>
> Regards<br>
</span><div class="HOEnZb"><div class="h5">> ᐧ<br>
><br>
> On Wed, Jun 1, 2016 at 1:19 AM, Marcel Wiesweg <<a href="mailto:marcel.wiesweg@gmx.de">marcel.wiesweg@gmx.de</a>><br>
><br>
> wrote:<br>
> > Please check the context where it is called, but I am quite sure that<br>
> > there is<br>
> > a special meaning in setting album root to 0.<br>
> > I'm sure there is a similar case with deleted images where album is set to<br>
> > 0,<br>
> > but the entry is preserved in case the image reappears at a different<br>
> > place<br>
> > (moving files where the removal is noticed first)<br>
> ><br>
> > Marcel<br>
> ><br>
> > > Hello.<br>
> > ><br>
> > > I was facing this error from past few days:<br>
> > ><br>
> > > MariaDB [digikam]> update Albums set albumRoot=0 where id=10;<br>
> > ><br>
> > > > ERROR 1452 (23000): Cannot add or update a child row: a foreign key<br>
> > > > constraint fails (`digikam`.`Albums`, CONSTRAINT `Albums_AlbumRoot<br>
> > > > s` FOREIGN KEY (`albumRoot`) REFERENCES `AlbumRoots` (`id`) ON DELETE<br>
> > > > CASCADE ON UPDATE CASCADE)<br>
> > ><br>
> > > I figured out that as 'id' is AlbumRoots table is not 0. So 'albumRoot'<br>
> ><br>
> > in<br>
> ><br>
> > > Images table can't be set to 0. This is I think the possible reason for<br>
> ><br>
> > FK<br>
> ><br>
> > > constraint failing.<br>
> > ><br>
> > > I used this statement instead & it worked:<br>
> > ><br>
> > > MariaDB [digikam]> update Albums set albumRoot=1 where id=10;<br>
> > ><br>
> > > > Query OK, 0 rows affected (0.06 sec)<br>
> > > > Rows matched: 1  Changed: 0  Warnings: 0<br>
> > ><br>
> > > Please look into this.<br>
> > ><br>
> > > Regards<br>
> > > ᐧ<br>
> ><br>
> > _______________________________________________<br>
> > Digikam-devel mailing list<br>
> > <a href="mailto:Digikam-devel@kde.org">Digikam-devel@kde.org</a><br>
> > <a href="https://mail.kde.org/mailman/listinfo/digikam-devel" rel="noreferrer" target="_blank">https://mail.kde.org/mailman/listinfo/digikam-devel</a><br>
<br>
_______________________________________________<br>
Digikam-devel mailing list<br>
<a href="mailto:Digikam-devel@kde.org">Digikam-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/digikam-devel" rel="noreferrer" target="_blank">https://mail.kde.org/mailman/listinfo/digikam-devel</a><br>
</div></div></blockquote></div><br></div>