that's okay. I anyway assume that there was some incomplete porting from dbconfig to in-code queries.
The function takes the parentid as parameters but the parameter is commented out in the function definition in the cpp file.
Also, two queries need the parentid as input but do not get it and the syntax for the parameters is :parentid, so it looks
as dbconfig syntax to me.
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)
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
forth and back. But it was not really stable as other (parent) tags were also corrupted and I could not see why.
I think we will have two possibilities:
1) A DB update for MySQL which contains only a functionality to correct the lft and rgt values according to the parentid property
2) A DB update switching to another approach of handling tag trees for MySQL. There is an open discussion on dev list already.
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.
It would be interesting, for what functionality the lft and rgt values are needed. It is possible, that there is a much better approach.
If I have the time today, I will take a look at it.
Am 10.08.2017 um 10:58 schrieb Swati Lodha:
|Free forum by Nabble||Edit this page|