Move an information object can break the nested set
|Category:||Data model / ORM||Estimated time:||20.00 hours|
|Target version:||Release 2.4.0|
|Google Code Legacy ID:||atom-2246||Tested version:|
- search:populate QubitSearch
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
#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
#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.
#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.