Self-explanatory.

Comments

damien tournoud’s picture

And of course that last query breaks everything down.

On installation for example:

variable_init() -> cache_get() -> db_select() -> looks for DatabaseStatement_* -> calls class_exists() -> calls _registry_check_code -> try to load the lookup cache with cache_get() -> db_select() -> looks for DatabaseStatement_* -> fails

We need to make that whole damn registry more robust.

damien tournoud’s picture

Status: Active » Needs review
StatusFileSize
new980 bytes

And the patch that breaks stuff.

Status: Needs review » Needs work

The last submitted patch failed testing.

lilou’s picture

The field 'create' should be 'created'.

catch’s picture

Title: cache.inc is not fully converted to the new database API » cache.inc cannot be fully converted to dbtng
Category: task » bug
Priority: Normal » Critical

Refocusing this issue since it's a bit abandoned.

damien tournoud’s picture

StatusFileSize
new865 bytes

This is still current. Here is a reroll.

damien tournoud’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch failed testing.

Anonymous’s picture

Issue tags: +Registry

subscribing, adding Registry tag.

catch’s picture

Priority: Critical » Normal

At this point we probably just need to document the interdependency then bump this to D8.

damien tournoud’s picture

The DBTNG specific autoloader should be able to workaround this. Let's revive this issue.

eric_a’s picture

We got manual class loading in the database system. (#851136: Make the database autoloading more robust).
Currently we have a db_select() in DrupalDatabaseCache::getMultiple() *and* we have cache_get() deferring to DrupalDatabaseCache::getMultiple().
However, while the class loading issue has been fixed we now have big performance problems with the page cache: #1064212: Page caching performance has regressed by 30-40%

chx’s picture

Status: Needs work » Closed (fixed)