Bug #4194

Move an information object can break the nested set

Added by Jesús García Crespo over 8 years ago. Updated about 4 years ago.

Status:VerifiedStart date:
Priority:MediumDue date:
Assignee:-% Done:

0%

Category:Data model / ORMEstimated time:20.00 hours
Target version:Release 2.4.0
Google Code Legacy ID:atom-2246 Tested version:
Sponsored:No Requires documentation:

Description

To reproduce this error:
  1. search:populate QubitSearch

Resulting error:

QubitSearch >> Foo inserted (30.43s) (13/15)
QubitSearch >> Bar inserted (30.47s) (14/15)
PHP Fatal error: Call to a member function getTitle() on a non-object in lib/QubitSearch.class.php on line 421

Fatal error: Call to a member function getTitle() on a non-object in lib/QubitSearch.class.php on line 421

[g] Legacy categories: Search / browse


Related issues

Related to Access to Memory (AtoM) - Bug #9401: Fix transaction filter and use transactions for all SQL u... Verified 02/03/2016
Related to Access to Memory (AtoM) - Feature #9945: Perform all Move operations via the job scheduler Verified 05/31/2016

History

#1 Updated by Jesús García Crespo over 8 years ago

  • Subject set to Move an information object can break the nested set

Forget my patch above. I saw in one user database that after trying to move an object unsuccessfully (error 500), the nested set was broken. The information object hierachy was broken (unexpected lft/rgt values), fortunately the nested set rebuild task fixed it.

This hierarchy problem was causing the issue described above. Summary updated.

[g] New owner: Jesús García Crespo

#2 Updated by Jesús García Crespo over 8 years ago

If you run into the same problem, please make sure that you rebuild the nested set and the search index to make sure that everything is okay in the database before continue working.

$ php symfony propel:build-nested-set
$ php symfony search:populate QubitSearch

#3 Updated by Anonymous over 8 years ago

  • Target version changed from Release 1.2.1 to Release 1.3

[g] Labels added: Milestone-Release-1.3
[g] Labels removed: Milestone-Release-1.2.1

#4 Updated by David Juhasz almost 8 years ago

  • Priority changed from Critical to High

[g] Labels added: Priority-High
[g] Labels removed: Priority-Critical

#5 Updated by Jesús García Crespo over 7 years ago

  • Category set to Data model / ORM
  • Target version set to Release 1.4.0
  • Sponsored set to No

We suspect that the SQL operations are not being grouped in a transaction. It would be nice to debug it and find if it is true.
Also, the fact that AtoM uses persistent connections may be related? It seems that transactions are specially problematic within persistent connections.

#6 Updated by David Juhasz over 7 years ago

  • Description updated (diff)

#7 Updated by David Juhasz over 7 years ago

  • Priority changed from High to Medium
  • Estimated time set to 20.00

#8 Updated by José Raddaoui Marín almost 7 years ago

Hi Jesús,

Could you give more instructions on how to reproduce this issue?

Thanks ;)

#9 Updated by Jesús García Crespo almost 7 years ago

I wish I could :)

#10 Updated by Dan Gillean almost 7 years ago

  • Target version changed from Release 1.4.0 to Release 2.1.0

#11 Updated by Jesús García Crespo almost 6 years ago

  • Target version changed from Release 2.1.0 to Release 2.2.0

#12 Updated by Sarah Romkey over 5 years ago

  • Target version deleted (Release 2.2.0)

#13 Updated by David Juhasz over 4 years ago

  • Related to Bug #9401: Fix transaction filter and use transactions for all SQL updates added

#14 Updated by Jesús García Crespo over 4 years ago

  • Assignee deleted (Jesús García Crespo)

#15 Updated by Dan Gillean about 4 years ago

  • Related to Feature #9945: Perform all Move operations via the job scheduler added

#16 Updated by Dan Gillean about 4 years ago

  • Status changed from New to Verified
  • Target version set to Release 2.4.0

I'm marking this ticket as verified until proven otherwise. The primary reason for implementing #9945 (Perform Move operations via the job scheduler) was to resolve repeated issues such as this. Further, re-adding support for transactions via #9401 will also help to resolve this - if the operation is not complete, then the state should be rolled back.

Also available in: Atom PDF