wrapper throws exceptions for properties that are declared in the info

... 'sorry' for having to confirm this bug! I am using the latest 'SPARQL 7.x-2.0-alpha4 (2011-Oct-01)' -- the above reported error by @mwidner still occurs! Changing the status of this issue.

I am having the same issue, please help

I have commented lines 23-25 in \sites\all\modules\entity\modules\callbacks.inc

 if (!isset($node->book['bid'])) {
      throw new EntityMetadataWrapperException('This node is no book page.');
    }

and my content saved, but i know that is wrong way. I am trying to reproduce example https://www.ibm.com/developerworks/web/library/wa-datasets/#iratings , actually i stucked at "Prepare a page to display the SPARQL View results" part when i was not able to add new content of type Agency page.

I am getting the same EntityMetadataWrapperException error trying to add a basic page. Am using Drupal 7.10, ARC2 library in sites/all/libraries/ARC2/arc, Chaos tool suite (ctools) 7.x-1.x-dev, Entity API 7.x-1.0-rc1, Libraries API 7.x-1.0, RDF Extensions 7.x-2.x-dev, SPARQL 7.x-2.0-alpha4, SPARQL Views 7.x-2.x-dev, Views 7.x-3.0.

My site primarily consists of Basic Pages, collected into 2 Books.

See also: http://drupal.org/node/1406984 (perhaps relevant?).

I can confirm this bug using the latest entity API dev version. Even though you found this bug in SPARQL Endpoint, it in fact is coming from the entity API integration in RDFx: another way to reproduce this bug is to install restws with rdfx and the book module enabled, and browse to node/1.rdf.

Moving to the Entity API queue. I've done a bit of debugging and found this is triggered by doing $property->access('view') in rdfx_get_rdf_model().

For value() that's the expected behavior, e.g. see

    // Try using book properties for no book nodes.
    $wrapper = entity_metadata_wrapper('node', $node3);
    $this->assertException($wrapper, 'book');

However, according the function docs $property->access('view') shouldn't throw an exception. Attached patch should fix that, please test whether it helps.

This patch does not solve the bug. I did a bit more debugging in around that hunk in propertyAccess(); and found that removing

    if ($op == 'view' && $this->$name instanceof EntityDrupalWrapper && !$this->$name->entityAccess($op, $account)) {
      return FALSE;
    }

solves the issue... and in particular, it seems to !$this->$name->entityAccess($op, $account) that triggers the exception.

@score: Just tried the hack of removing

<?php
if ($op == 'view' && $this->$name instanceof EntityDrupalWrapper && !$this->$name->entityAccess($op, $account)) {
      return FALSE;
    }
?>

I'm using version Entity 7.x-1.0-rc3+2-dev.

Results: Does not fix the error.

This error occurs AFTER deleting a node that is also an OG group. The node (Bundle) is successfully deleted and all seems OK until the /user is executed. then an exception is thrown with the following error:

EntityMetadataWrapperException: Missing data values. in EntityMetadataWrapper->value() (line 83 of/.../sites/all/modules/entity/includes/entity.wrapper.inc).

The user's profile can not be viewed or saved without generating the above. (Interesting sidenode; one can navigate directly to /user/%uid/edit. That produces a screen without error, but a save results again in the error).

Finally, executing a Clear All Caches from either admin/config/development/performance or a drush cc all clears up the problem.

After logging this original post, I loaded Entity 7.x-1.0-rc3. Same problem.

I am using Commerce download profile with RESTful Web Service and got this exact eroor while trying to access http://myweb/node/1.xml

Patch does not change a thing.

#7: entity_access_exception.patch queued for re-testing.

@duvalbruno,

Your issue is probably with restws, not entity. See #1956752: restws_property_access_filter() can fail on empty properties for a patch.

I am having the same issue, I have applied the patch as post #7 suggested and still the same problem. In my case I do not have the restws module installed.

I just tried deleting an OG group node and going to /user. No error.

This is with Entity 7.x-1.x dev 028b66f, and OG 7.x-2.2

The patch in #7 doesn't solve the problem because ->entityAccess() also calls ->value() -- so we need similar logic there, e.g.:

diff --git a/includes/entity.wrapper.inc b/includes/entity.wrapper.inc
index d5d22ac..022c9a4 100644
--- a/includes/entity.wrapper.inc
+++ b/includes/entity.wrapper.inc
@@ -810,7 +810,11 @@ class EntityDrupalWrapper extends EntityStructureWrapper {
    * @see entity_access()
    */
   public function entityAccess($op, $account = NULL) {
-    $entity = $this->dataAvailable() ? $this->value() : NULL;
+    try {
+      $entity = $this->dataAvailable() ? $this->value() : NULL;
+    } catch (EntityMetadataWrapperException $e) {
+      $entity = NULL;
+    }
     return entity_access($op, $this->type, $entity, $account);
   }
 

HOWEVER, I don't think that the "expected" result as described in #7 is correct. See https://drupal.org/node/1956752#comment-7717521. As @joachim argues there, if an entity advertises a property, it certainly shouldn't throw an exception if someone tries to access that property. I think the best solution is the one @joachim proposes in that thread - simply to return NULL if the book is not a book node, as in the attached patch.

btw - are we sure that the issues with OG are related? They dont seem to have to do with the book property at all.

Better title.

I've just seen this also with the "file" property of an uninitialized image field property -- in this case, there's a "data not available" exception.

I'm getting this updating (or failing to) the search api index using search_api_db. I agree with the patch that returns NULL for defined properties without values, though.

I have the patch from #15 applied on project-drupal.redesign.devdrupal.org to help #1710850: Deploy RestWS for D7 project issue JSON.

15: 1330086-15-entity-book-exception.patch queued for re-testing.

Re-reading the EMW::value() docs I must agree that it does not make sense to throw an exception in this case. Patch in #25 looks good and comes with test coverage, thus committed - thanks!

thanks!

I promised yesCT I would test this patch, sorry for being late to the party, but I'm glad fago beat me to it, since this patch/7.x-1.x fixes the initial problem which was reported against the RDF contrib module. Thank you guys!