Error: Call to a member function delete() on null in editPhysicalObjectsAction.class.php:111

[mmikit...@gmail.com]

Hello,

When I attempt to delete the Container of a File in the "Link Physical storage" action, I observe a blank white screen and the stack trace below. This behaviour is observed with some, not all, objects. I found some relevant posts (see below), but I'm very reluctant to alter the database without understanding the structure.

Could someone please advise on how to resolve this problem, and prevent it from occurring again?

Stack trace

2017/07/14 11:29:07 [error] 7089#7089: *14928 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Uncaught Error: Call to a member function delete() on null in /usr/share/nginx/atom/apps/qubit/modules/informationobject/actions/editPhysicalObjectsAction.class.php:111
Stack trace:
#0 /usr/share/nginx/atom/apps/qubit/modules/informationobject/actions/editPhysicalObjectsAction.class.php(127): InformationObjectEditPhysicalObjectsAction->processForm()
#1 /usr/share/nginx/atom/cache/qubit/prod/config/config_core_compile.yml.php(966): InformationObjectEditPhysicalObjectsAction->execute(Object(sfWebRequest))
#2 /usr/share/nginx/atom/cache/qubit/prod/config/config_core_compile.yml.php(961): sfExecutionFilter->executeAction(Object(InformationObjectEditPhysicalObjectsAction))
#3 /usr/share/nginx/atom/cache/qubit/prod/config/config_core_compile.yml.php(947): sfExecutionFilter->handleAction(Object(sfFilterChain), Object(InformationObjectEditPhysicalObjectsAction))
#4 /usr/share/nginx/atom/cache/qubit/prod/config/config_core_compile.yml.php(1045): sfExecutionFilter->execute(Object(sfFi" while reading response header from upstream, server: libarchives.wlu.ca, request: "POST /index.php/minute-books-journals-register/informationobject/editPhysicalObjects HTTP/1.1", upstream: "fastcgi://unix:/run/php7.0-fpm.atom.sock:", host: "libarchives.wlu.ca", referrer: "https://libarchives.wlu.ca/index.php/minute-books-journals-register/informationobject/editPhysicalObjects"

Here are some relevant posts:

* https://groups.google.com/forum/#!msg/ica-atom-users/YRbU3uhZcb0/OGkNuu1mCQAJ
* https://groups.google.com/forum/#!msg/ica-atom-users/ZElzuHT_g40/z-XFsDFIFAAJ
* https://groups.google.com/forum/#!msg/ica-atom-users/Z8xPAMr0hiY/60L714l3EQAJ

My environment:
* AtoM 2.3.0 - 138
* nginx version: nginx/1.10.3 (Ubuntu)
* PHP 7.0.18-0ubuntu0.16.04.1
* mysql  Ver 14.14 Distrib 5.7.18
* Ubuntu 16.04.2 LTS

Thank you,
matt

[Dan Gillean]

Hi Matt,

First, thank you for posting a detailed message with the error log and your AtoM version information, and for looking through the forum prior to posting!

From the sounds of it, I think you have correctly identified that this is being caused by some corruption in your database. I'm guessing that you had an earlier version than 2.3 installed previously and have upgraded at some point?

The most common cause of database corruption in AtoM is when a long-running task (such as an import via the user interface, a move operation, a large update that afects many records, etc) that is completed sychronously (ie. on request, in real-time) via the web browser times out before the task can complete, leaving partial data rows in your database. In version 2.3, we have introduced SQL transactions to AtoM, meaning that if an operation aborts mid-process, then the database should roll itself back to the last good state. Additionally, we continue with each release to move more and more of these long running tasks to be performed asynchronously in the background by AtoM's job scheduler. For example, in our upcoming 2.4 release, Imports and Exports performed via the user interface will now be handled by the job scheduler. Hopefully this will mean that the likelihood of you encountering such issues going forward will be greatly reduced.

I will have to ask our developers if they can look at the specific error message you've provided and suggest a query or a course of action that will help us resolve it. In the meantime, here are a couple things to get you started.

First, to learn more about the AtoM database and data model, you might want to look at the Entity Relationship Diagrams we have available on our wiki:

• https://wiki.accesstomemory.org/Development/ERDs

It's also very easy to set up a local test AtoM instance on a local laptop or computer, using our Vagrant box, if you want to play around with an AtoM instance without messing up your production instance.

• Vagrant documentation: https://www.accesstomemory.org/docs/latest/dev-manual/env/vagrant/
• Slides: https://www.slideshare.net/accesstomemory/atom-and-vagrant-installing-and-configuring-the-atom-vagrant-box-for-local-testing-and-development
• Videos 1-3 in this tutorial series also cover Vagrant installation and configuration.

The slides are probably the most accessible of the resources.

We have other slides that might be of use to you as well. These include:

• Get to know AtoM's code base: https://www.slideshare.net/accesstomemory/get-to-know-atoms-codebase
• Constructing SQL queries for AtoM: https://www.slideshare.net/accesstomemory/constructing-sql-queries-for-atom
• AtoM's Command-Line tasks: https://www.slideshare.net/accesstomemory/atoms-command-line-tasks-an-introduction
  

The SQL slides, in slide 4, will also show you how you can install MySQL Workbench and use it with the Vagrant box to provide yourself with a graphical interface for interacting with the database. This can make navigation and manipulation much easier! We at Artefactual have also used phpMyAdmin for this purpose. You can use a similar approach with your production AtoM instance when you are ready. 

Some of the user forum threads you found include some AtoM command-line tasks that can be used for maintenance and troubleshooting common AtoM issues. The slide deck on command-line tasks will explain these in greater detail. In general, the tasks recommended in those threads are non-destructive so you can try them in your AtoM instance to see if it helps resolve the issues: 

• Rebuild the nested set: php symfony propel:build-nested-set
• Generate slugs: php symfony propel:generate-slugs
• Repopulate the search index: php symfony search:populate
• Clear the cache: php symfony cc
• Restart PHP-FPM: sudo systemctl restart php7.0-fpm

However, given that most of these other threads are about missing publication status values, and yours may be about physical storage values, these may not resolve your issues either - but it's always good to try and rule out some things. The slides will explain more on what each task is used for. 

Finally, any of the queries in the threads you've found that are SELECT queries will not actually change anything in your database - they will simply return results in the console, so you are safe to try those without much risk. It's always wise to make a back-up of your data first, just in case - but it is the INSERT queries that are actually adding new data to the database, and with which you must be very cautious. 

I'll see if the developers have specific suggestions for you. 

Cheers, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-users+unsubscribe@googlegroups.com.
To post to this group, send email to ica-ato...@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/27e66f2d-1b7d-4baf-be80-2816c0719a55%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[José Raddaoui]

Hi Matt,

From the tasks Dan said I think "php symfony propel:generate-slugs" may be the one that helps you, as it's trying to get and delete the resource from a route param. where it's failing.

Regards.

[mmikit...@gmail.com]

Hello Dan and José,

Thank you for assisting me in diagnosing and fixing the problem.

I explored the differences between a physical container that can be removed from an object from a physical container that cannot be removed from the same object, and here are my diagnostic notes. I would appreciate your guidance on how to proceed.

    * php symfony propel:build-nested-set

      x No change

    * php symfony propel:generate-slugs

      x No change

    * Sample object: "Fond S506: File 14.22 - The pipe organs of Newfoundland and Labrador, Peters"

      ! Can delete "S506 Box 45"

      ! Cannot delete "S506 Box 122"

          physical_object_i18n: "S506 Box 45" id = 51245

          physical_object_i18n: "S506 Box 122" id = 74556

          physical_object: id = 51245 exists

          physical_object: id = 74556 exists

          information_object_i18n: "The pipe organs of ..." id = 71498

          information_object: "File 14.22" id = 71498

          information_object: "3.7", id = 48840, rgt=51245

          relation: "object_id = 71498" has two relations to 74556 and 51245

          relation: "subject_id = 51245" has 8 relations to other objects

          relation: "subject_id = 74556" has 17 relations to other objects

          ! slug: "object_id = 51245" has slug = "s506-box-46" (why not "s506-box-45"?)

          ! slug: "object_id = 74556" has slug = "s506-box-129" (why not "s506-box-122"?)

     Perhaps the issue is related to a mismatch between the slug components and the corresponding object name?

          physical_object_i18n: "S506 Box 46" id = 51254

          physical_object_i18n: "S506 Box 129" id = NULL (does not exist)

          slug: "object_id = 51254" has slug = "s506-box-47" (why not "S506-box-46"?)

          physical_object 64208 points to "s506-box-122" but the object label is " S506 Box 117"

Please confirm whether the mismatch between the object names and slug component values is relevant to the problem.

Thank you,

matt

[José Raddaoui]

Hi Matt,

That shouldn't be a problem, if two similar slugs are created AtoM adds or increases a counter in the end to avoid duplications, in this case that number may belong to the resource, so it may be confusing. Anyway if the slugs are populated that shouldn't be the problem.

Those "physical_object" rows must have another row in the "object" table, with the same id. Could you check that? If that's not the problem and you can send me a database dump via personal email, I'll try to take a deeper a look.

Regards. 

[mmikit...@gmail.com]

Hello José,

Each physical_object has a corresponding object value:

mysql> select * from object left outer join physical_object using (id) where id in (51245, 74556);
+-------+---------------------+---------------------+---------------------+---------------+---------+-----------+------+------+----------------+
| id    | class_name          | created_at          | updated_at          | serial_number | type_id | parent_id | lft  | rgt  | source_culture |
+-------+---------------------+---------------------+---------------------+---------------+---------+-----------+------+------+----------------+
| 51245 | QubitPhysicalObject | 2016-05-24 12:21:59 | 2016-05-24 12:21:59 |             0 |     183 |      NULL | 1667 | 1668 | en             |
| 74556 | QubitPhysicalObject | 2016-08-29 11:43:12 | 2017-07-14 06:12:48 |             0 |     183 |      NULL | 2845 | 2846 | en             |
+-------+---------------------+---------------------+---------------------+---------------+---------+-----------+------+------+----------------+
2 rows in set (0.00 sec)

José, I'll get in touch with you offline about diagnosing this further.

Thank you

[José Raddaoui]

For future reference,

We were in the right track as it was a malformed slug causing the issue, but we've find out that not all the AtoM entities with slugs are being fixed in the generate slugs task.

The following ticket has been created to improve that task:

https://projects.artefactual.com/issues/11385