<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hey Swati,<br>
<br>
that's okay. I anyway assume that there was some incomplete porting
from dbconfig to in-code queries.<br>
The function takes the parentid as parameters but the parameter is
commented out in the function definition in the cpp file.<br>
Also, two queries need the parentid as input but do not get it and
the syntax for the parameters is :parentid, so it looks<br>
as dbconfig syntax to me.<br>
<br>
And in fact, I was able to fix the problem partially by making the
two queries which cannot be used in a prepared statement (LOCK and
UNLOCK)<br>
direct SQL queries. Giving the parentid as parameter for the two
queries that need it also reduced the database corruption after I
moved a corrupted tag<br>
forth and back. But it was not really stable as other (parent) tags
were also corrupted and I could not see why.<br>
<br>
I think we will have two possibilities:<br>
1) A DB update for MySQL which contains only a functionality to
correct the lft and rgt values according to the parentid property<br>
2) A DB update switching to another approach of handling tag trees
for MySQL. There is an open discussion on dev list already.<br>
3) I didn't mention this possibility as a normal user would not like
it. The users could create a new database. But here, there is a
probability of loss of information as MySQL support is not yet
stable.<br>
<br>
It would be interesting, for what functionality the lft and rgt
values are needed. It is possible, that there is a much better
approach.<br>
If I have the time today, I will take a look at it.<br>
<br>
Cheers,<br>
Mario<br>
<br>
<div class="moz-cite-prefix">Am 10.08.2017 um 10:58 schrieb Swati
Lodha:<br>
</div>
<blockquote type="cite"
cite="mid:CAHkpQmigMYz-z2z144i1Ak6dpmCaHbEVR+WUqiC-BKmr46TNdw@mail.gmail.com">
<div dir="ltr">Hi
<div><br>
</div>
<div>I'm currently at home for 2 days due to some family reasons
and I don't have my laptop for work. I'll definitely take a
look at the Bugzilla entry and get back to you.</div>
<div><br>
</div>
<div>Apologies for inconvenience. </div>
<div><br>
</div>
<div>Regards</div>
</div>
<div hspace="streak-pt-mark" style="max-height:1px"><img alt=""
style="width:0px;max-height:0px;overflow:hidden"
src="https://mailfoogae.appspot.com/t?sender=ac3dhdGlsb2RoYTI3QGdtYWlsLmNvbQ%3D%3D&type=zerocontent&guid=96e843b0-a826-496b-935f-971acd1ddd4f"
moz-do-not-send="true"><font size="1" color="#ffffff">ᐧ</font></div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Thu, Aug 10, 2017 at 1:33 AM, Mario
Frank <span dir="ltr"><<a
href="mailto:mafrank@uni-potsdam.de" target="_blank"
moz-do-not-send="true">mafrank@uni-potsdam.de</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Hey
Gilles,<br>
<br>
I tried to fix it but I do not see a fast way.<br>
<br>
Also, I do not any sense in the structure of the table. I
have the<br>
following problems:<br>
<br>
Why do both the entries in Tags and TagsTree have a pid?<br>
Why are the columns lft and rgt needed? Isn't the parent of
a tag<br>
completely sufficient? As I know, there is also an ON DELETE
CASCADE<br>
for MySQL and it is possible to reference the parent as
foreign key to<br>
the same<br>
table.<br>
<br>
Swati,<br>
Can you take a look at the following bug? I think you are
more fit in<br>
MySQL than I am.<br>
<a href="https://bugs.kde.org/show_bug.cgi?id=383326"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://bugs.kde.org/show_bug.<wbr>cgi?id=383326</a><br>
<br>
Cheers,<br>
Mario<br>
<br>
<br>
<br>
Am 09.08.2017 um 20:17 schrieb Gilles Caulier:<br>
> Mario,<br>
><br>
> You can ask to Swati. She improve the Mysql dtatabase
backend/schema<br>
> while summer 2016, and i'm sure that she review this
kind of problem<br>
> already. She has also certainly a Mysql DB reday to
test.<br>
><br>
> Gilles<br>
><br>
> 2017-08-09 20:07 GMT+02:00 Mario Frank <<a
href="mailto:mafrank@uni-potsdam.de"
moz-do-not-send="true">mafrank@uni-potsdam.de</a>>:<br>
>> Hey Meku,<br>
>><br>
>> I think this is a bug. But I<br>
>><br>
>> 1) do not have a MySQL (and currently not the
possibility to create one) to<br>
>> test and confirm<br>
>><br>
>> 2) Thus also cannot fix the problem shorthand.<br>
>><br>
>> I opened a bugzilla entry with your and mine
findings here:<br>
>><br>
>> <a
href="https://bugs.kde.org/show_bug.cgi?id=383326"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://bugs.kde.org/show_bug.<wbr>cgi?id=383326</a><br>
>><br>
>> I hope one of the other devs can fix it faster than
I.<br>
>><br>
>> Best,<br>
>><br>
>> Mario<br>
>><br>
>><br>
>> "Am 09.08.2017 um 14:36 schrieb meku:<br>
>> Studying the database there appears to be some
inconsistent data in the Tags<br>
>> table causing this.<br>
>><br>
>> Tag B probably used to be a child of Tag A, but
some time ago Tag B was<br>
>> moved to the root.<br>
>><br>
>> Tag B's 'pid' is '0' because it a child of the root
node, but the 'lft' and<br>
>> 'rgt' fields have not been updated so still fall
within the range of Tag A's<br>
>> 'lft' and 'rgt'.<br>
>><br>
>> If browsing using Tags with "Include Tag Sub-Tree"
enabled relies on the<br>
>> 'lft' and 'rgt' fields then it would explain the
inconsistent behaviour I'm<br>
>> seeing - and it appears it only happens to Tags
that have been moved in the<br>
>> hierarchy.<br>
>><br>
>> Is this a bug, and is there a mysql query to repair
it?"<br>
>><br>
>> Am 08.08.2017 um 15:45 schrieb Mario Frank:<br>
>><br>
>> Hi Meku,<br>
>><br>
>> this is odd, as when the disabling solves the
problem, the unexpected items<br>
>> must have<br>
>><br>
>> a tag that is a child tag of A. At least for sanity
reasons.<br>
>><br>
>> The source code itself looks good. Gilles, can you
take a look at the<br>
>> definition of<br>
>><br>
>> getItemIDsInTagRecursive in the dbconfig? For me,
it looks correct, too.<br>
>><br>
>> Can you send a screenshot or something like this?<br>
>><br>
>> Cheers,<br>
>> Mario<br>
>><br>
>> Am 08.08.2017 um 15:10 schrieb meku:<br>
>><br>
>> Hi Mario,<br>
>><br>
>> Yes, disabling "Include Tag Sub-Tree" hides the
unexpected items.<br>
>><br>
>> Tag B is not a child of Tag A and the unexpected
items do not have Tag A or<br>
>> any of A's child tags.<br>
>><br>
>> I can work with mysql queries.<br>
>><br>
>> On 8 August 2017 at 22:55, Mario Frank <<a
href="mailto:mafrank@uni-potsdam.de"
moz-do-not-send="true">mafrank@uni-potsdam.de</a>>
wrote:<br>
>>> Hi Meku,<br>
>>><br>
>>> can you check the following?<br>
>>><br>
>>> In menu View: is the option "include tag tree"
(I do not know how it is<br>
>>> called exactly in the English version, I have
the German one)<br>
>>><br>
>>> checked? If yes, images with subtags are also
shown in the browser and<br>
>>> may have tag B.<br>
>>><br>
>>> Otherwise, do you have experience with MySQL
queries?<br>
>>><br>
>>> Cheers,<br>
>>><br>
>>> Mario<br>
>>><br>
>>><br>
>>> Am 08.08.2017 um 14:46 schrieb meku:<br>
>>>> I am seeing some inconsistent behaviour
when browsing items by Tags.<br>
>>>><br>
>>>> Selecting a single tag (A) in the tree
shows all items with tag (A)<br>
>>>> but also unrelated items with tag (B). So
far I have only discovered<br>
>>>> this happening for a few specific tags, but
it continues happening<br>
>>>> after restarting Digikam.<br>
>>>><br>
>>>> If I use the Search for tag (A) then it
shows the expected results,<br>
>>>> it's only within the Tag browser that this
issue is occurring.<br>
>>>><br>
>>>> Using Digikam 5.7 appbundle with mysql.<br>
>><br>
>><br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div class="gmail_signature" data-smartmail="gmail_signature">
<div dir="ltr">Swati Lodha</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>