I'm using scald in a cope environment and transformed the atom entity in a remote entity. The only PITA I ran into right now is scald_is_registered(), which bypasses the entity controller for loading. Looking at the code I do not see why it's not a simple scald_fetch() operation - as entity loading has already the static memory cache. This should be better than loading it twice - once with scald_is_registered() and another time in a probably anyway pursued scald_fetch() call.

Thus, attached patch deprecates scald_is_registered() in favor of scald_fetch().

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Status: Needs review » Needs work

The last submitted patch, d7_scald_is_registered.patch, failed testing.

fago’s picture

Title: Deprecate scald_is_registered() by entity_load() » scald_is_registered() should leverage entity_load()
Status: Needs work » Needs review
FileSize
1.49 KB

Figured that scald_fetch() does permission checking as well - thus it's not really deprecated. Instead it's basically the same as entity load, thus I've updated the patch to make it use entity load instead.

Also, re-rolled patch with proper paths.

jcisio’s picture

scald_is_registered is a lightweight way to check and get atom properties, without loading the whole entity. It is like $GLOBALS['user']. This was a useful optimization, but I'm not sure if it is still now.

  • Commit 149b585 on 7.x-1.x authored by fago, committed by jcisio:
    Issue #2221219 by fago: Scald_is_registered() should leverage...
jcisio’s picture

Status: Needs review » Fixed

I've just checked and scald_is_registered() is only used in scald_render() now, so there is no need for a dirty db_select that bypasses the entity controller. Fixed a few comments and committed. Thanks.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.