Closed (fixed)
Project:
Drupal core
Version:
7.x-dev
Component:
base system
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
8 Dec 2008 at 00:03 UTC
Updated:
1 Jul 2012 at 20:56 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
damien tournoud commentedAnd 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.
Comment #2
damien tournoud commentedAnd the patch that breaks stuff.
Comment #4
lilou commentedThe field 'create' should be 'created'.
Comment #5
catchRefocusing this issue since it's a bit abandoned.
Comment #6
damien tournoud commentedThis is still current. Here is a reroll.
Comment #7
damien tournoud commentedComment #9
Anonymous (not verified) commentedsubscribing, adding Registry tag.
Comment #10
catchAt this point we probably just need to document the interdependency then bump this to D8.
Comment #11
damien tournoud commentedThe DBTNG specific autoloader should be able to workaround this. Let's revive this issue.
Comment #12
eric_a commentedWe 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%
Comment #13
chx commented