Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
I use Drupal 7.7 on XAMPP with Win7.
Notice: Undefined index: bundles in C:\xampp\htdocs\drupal\modules\field\field.info.inc on line 576
Notice: Undefined index: bundles in C:\xampp\htdocs\drupal\modules\field\field.info.inc on line 576
Notice: Undefined index: bundles in C:\xampp\htdocs\drupal\modules\field\field.info.inc on line 576
Warning: Invalid argument supplied for foreach() in C:\xampp\htdocs\drupal\modules\field\field.info.inc on line 215
Warning: Invalid argument supplied for foreach() in C:\xampp\htdocs\drupal\modules\field\field.info.inc on line 215
Warning: Invalid argument supplied for foreach() in C:\xampp\htdocs\drupal\modules\field\field.info.inc on line 215
Notice: Undefined index: schema_fields_sql in C:\xampp\htdocs\drupal\includes\entity.inc on line 265
Catchable fatal error: Argument 2 passed to SelectQuery::fields() must be an array, null given, called in C:\xampp\htdocs\drupal\includes\entity.inc on line 284 and defined in C:\xampp\htdocs\drupal\includes\database\select.inc on line 1320
I have to disable uuid using phpMyAdmin and then to use "update.php"!
Something is wrong.
Please help.
Thanks in advance
Comment | File | Size | Author |
---|---|---|---|
#40 | 1268602-40-uuid-build-entity-info.patch | 4.04 KB | zhangtaihao |
#34 | 1268602-34-uuid-crash-stale-schema_fields_sql.patch | 618 bytes | zhangtaihao |
#26 | uuid_schema_temp_fix.patch | 1.77 KB | mh86 |
#17 | 1268602-17-uuid-crash-undefined-schema_fields_sql.patch | 2.28 KB | zhangtaihao |
#13 | 1268602-13-trace1.txt | 3.93 KB | zhangtaihao |
Comments
Comment #1
Kristjan Logason CreditAttribution: Kristjan Logason commentedHave you looke at this. http://drupal.org/node/1256888 it just saved me
Comment #2
wusel CreditAttribution: wusel commentedIt is my first use of UUID, so here is no update.
I can not enable UUID the first time.
[update 05.09.2011]
The enabling of the module UUID crashes Drupal 7.7 and 7.8.
I get ONLY a white screen with the text (look at the code-box) of my issue.
I must unable this module (look at my issue: the text after the code-box) to get a working Drupal (without UUID).
So I can not use this module!
[/update 05.09.2011]
Another module needs this module, so what can I do?
Something is wrong!
Or I do not unterstand your link. Sorry... Can you or someone else help?
Thanks in advance
Comment #3
mh86 CreditAttribution: mh86 commentedsame as reported here #1259458: Undefined index: schema_fields_sql when clearing the caches
Comment #4
claudiu.cristeaClosed #1265918: Catchable fatal error: Argument 2 passed to SelectQuery::fields() must be an array, null given as duplicates this.
Comment #5
claudiu.cristeaSame here. Attached you can find a debug backtrace made with XDEBUG.
Comment #6
claudiu.cristeaThis seem to be the source of bug. I cannot figure out exactly what is causing.
Comment #7
mh86 CreditAttribution: mh86 commentedFor example the Field collection module implements hook_entity_info_alter and calls field_info_fields() which then invokes entity_get_info(). As pointed out in the comment in uuid_schema_alter() entity_get_info() should not be called within this function.
In my opinion uuid_schema_alter should be more robust against such operations.
Comment #8
claudiu.cristeaThe bug is caused by
uuid_schema_alter()
, more precise bydrupal_alter()
:Do you have Profile2 installed? Because it seems to me that this is triggered by
profile2_entity_info_alter()
.Comment #9
wusel CreditAttribution: wusel commented#8:
Yes, I have installed Profile2.
Comment #10
skwashd CreditAttribution: skwashd commentedThanks for the additional info. I'm on the road for most of this week, but I'll try to get this sorted ASAP.
Comment #11
claudiu.cristeaThis is quoted from
uuid_schema_alter()
and it seem that this is causing the issue. I believe that not adding some of the default values fromentity_get_info()
is causing the bug. This happens inhook_entity_info_alter()
when some entities have their type obtained from other entities (Profile2 does... he gets the type (bundle) from another entity - profile2_type). An then, because not all default values are set... at some point fails. For example ifhook_entity_info()
doesn't set the'bundles'
key, this is supplied inentity_get_info()
by adding an empty'bundles'
key.What I'm saying is that some of the "fancy logic for default values" are mandatory. Wanna check? Apply the attached patch. It simply replaces:
with the complete...
And it works. Don't know anything in this moment about side-effects of "caching too hard" but let's find if there's other side effect.
Comment #12
claudiu.cristeaThe patch from #11 fixes the bug but makes UUID not to work.
I came, in this patch, with a workaround by using the logic from
entity_get_info()
.entity_get_info()
must be provided in D8 with some cache reset mechanism as other function does.Comment #13
zhangtaihao CreditAttribution: zhangtaihao commentedInterestingly, this approach still works only if something else doesn't call
entity_get_info()
first when cache hasn't been rebuilt, e.g. Rules.In trace1 (attached), UUID has been installed first. After setting up Rules and creating a rule to react on "Drupal is initializing", an exception is thrown with
DrupalDefaultEntityController
trying to build a query with NULL on$this->entityInfo['schema_fields_sql']['base table']
.In trace2 (attached), Rules has been installed (and set up with the rule) first. When enabling UUID, I get a couple warnings and end up at the same exception. And yes, I've checked update.php before enabling UUID.
Comment #14
zhangtaihao CreditAttribution: zhangtaihao commentedI'm tentatively setting this to "needs work" based on the fact that Rules is a crucial module as well, despite the fact that UUID will go into Drupal 8 core.
Comment #15
zhangtaihao CreditAttribution: zhangtaihao commentedWe're effectively running into the same problem here, just at a different point in the recursion.
Trying to get entity info results in calls to
drupal_schema_fields_sql()
, which callsdrupal_get_schema()
(and in turn invokeshook_schema_alter()
). This means that, inevitably, by the timeuuid_schema_alter()
is invoked theentity_get_info()
will have begun - unless, of course, there's nothing callingentity_get_info()
before the entire cache has been rebuilt (i.e. schema is built before entity info), which I might add is not quite a reasonable assumption.I'll see if I can come up with anything else.
Comment #16
zhangtaihao CreditAttribution: zhangtaihao commentedI'll have to stop posting to quickly... Anyway, to continue:
The reason
entity_get_info()
doesn't work is the line in the function that tests whether the static$entity_info
is empty, which it won't be by the time it hitsdrupal_schema_fields_sql()
and soonuuid_schema_alter()
, preventing entity info other than the basic from being returned and thus precludinguuid_entity_info_alter()
from doing its job.I think I'm close to a workaround, if not a hack. Hopefully I'll be back with a patch.
EDIT:
Also, there's another crucial recursion: on the line in
entity_get_info()
(also in the patch in #12) where the first call todrupal_schema_fields_sql()
, the return value is supposed to be set into$entity_info[$name]['schema_fields_sql']['base table']
. However, how can it exist if our schema hasn't been built yet?EDIT2:
You could theoretically reset the cache for
entity_get_info()
by:However, that wouldn't solve the recursion problem. In fact, I believe it would cause it, since the
entity_get_info()
is stopping recursion, just incorrectly and returning the wrong data.Comment #17
zhangtaihao CreditAttribution: zhangtaihao commentedIT WORKS!!! It's bloody working!
That is, I imagine for most cases. The solution is basically to reset the static cache for
entity_get_info
so it could rebuild info from the ground up. A flag is introduced inuuid_schema_alter()
and set around the call toentity_get_info()
to prevent infinite recursion.The revelation I had was that the original problem occurs because neither entity info nor schema had been properly built, and race conditions essentially proliferated between modules that implemented any combination of those alter hooks. So, to fix it I had simply allowed the schema to build first without the uuid schema field [EDIT] so that entity info could be built with the uuid keys initialized [/EDIT]. By the time
uuid_schema_alter()
had been completed for a second time the schema field would be there. The schema cache will then eventually have been set twice, the first time without the uuid schema field, the second time with.@claudiu.cristea: I apologize for being presumptuous. You were right on the money with static reset for
entity_get_info()
.A possible problem I can see with this solution is when certain
hook_schema_alter()
implementations mutate. Some modules implementinghook_schema_alter()
could potentially change something twice. But because they really shouldn't, I think it's a reasonably safe assumption thathook_schema_alter()
could be invoked twice in one go without dire consequences.P.S. I've already tried removing the
_uuid_entity_get_info()
adaptation for setting up'schema_fields_sql'
with the initial assumption that it's not necessary foruuid_schema_generate()
. I've had no such luck, because any module that implementshook_entity_info_alter()
with a call toentity_get_info()
somewhere down the line (e.g. Field collection) presents the same problem:'schema_fields_sql'
doesn't exist.P.P.S. I'm also tentatively assigning myself to this issue since I've spent an exorbitant amount of time on it tracking down the workflow in core. @claudiu.cristea: please let me know if I'm being presumptuous again and feel free to change the assignment back to yourself.
Comment #18
mh86 CreditAttribution: mh86 commentedI think using entity info in hook_schema_alter() will always cause some troubles. Maybe we should add another hook for registering entities to the uuid system? I know that's a bit ugly, but what are the options? The suggested patches look quite complicated and don't fix all issues.
Comment #19
zhangtaihao CreditAttribution: zhangtaihao commentedUsing entity_get_info() in hook_schema_alter() seems to be a necessary evil, at least in the current architecture. The issue is that the 'uuid' flag in hook_entity_info() is used so widely and transparently that it would require any module implementing UUID (but not implemented on its behalf by UUID) to either add its own 'uuid' field like in Make it exportable or implement the hook you mentioned, which only gets used in the install file. This could become a deterrent to adding UUID support for a module.
Then again, 7.x-1.0-alpha2 has never been endorsed as a moderately stable release (apart from the "green" status). Until there's an upgrade path, the development head would be somewhat free to change.
Let's see what the maintainers have to say.
Comment #20
zhangtaihao CreditAttribution: zhangtaihao commentedComment #21
bennos CreditAttribution: bennos commentedsubscribing
Comment #22
bendiy CreditAttribution: bendiy commentedsub.
Breaks Profile2 install:
http://drupal.org/node/1260644
Comment #23
bendiy CreditAttribution: bendiy commentedI tested patch in #17 and it does fix the install issue with Profile2.
Comment #24
mh86 CreditAttribution: mh86 commentedI posted a patch in the Entity API issue queue which is about problems during cache rebuilding. These problems are caused by the use of API functions based on entity info in entity_info_alter hooks (#1290986: avoid entity_load() during entity info cache rebuilds). Solving the issue there might also help to get the current UUID hook_schema_alter() hack working.
Comment #25
zhangtaihao CreditAttribution: zhangtaihao commentedI'm actually inclined to propose a variant of
entity_exportable_schema_fields()
to provide UUID fields in schema for which implementing modules are responsible. Logically, modules providing entities (or providing UUID capability to entities) should by themselves provide the schema field they are declaring as UUID, much as they're declaring numeric identifiers, machine names, and revision keys.Don't get me wrong, @mh86, I agree that the cache rebuilding issue should be fixed. I'm just saying that using info declared in modules to globally alter the schema seems oddly illogical. As far as the Drupal core entity system is concerned, schema fields exist by the time entity info is
used[EDIT] being initialised [/EDIT].If anyone believes I'm mistaken about the core entity system (or even its future development), please quote some documentation or a statement made somewhere, perhaps in an issue, perhaps in an IRC log entry, so that we can all monitor where that's going and see how this schema issue should actually be resolved.
Comment #26
mh86 CreditAttribution: mh86 commentedI agree that having a separate hook is the best alternative. Nevertheless, fixing the Entity API (#1290986: avoid entity_load() during entity info cache rebuilds) might also have some impacts on this issue, but we'll see later on.
In the meanwhile I post a patch I'm using on a website (patch from #17 didn't work for me). This patch manually adds the schema definitions and hence works without any conflicts, but I only see it as temporary solution.
Comment #27
zhangtaihao CreditAttribution: zhangtaihao commentedI actually think your patch is there as far as workflow is concerned. From the Entity API's perspective, this is how it's supposed to be implemented. Looking at
uuid_entity_info_alter()
in uuid.entity.inc, UUID is implements itself on behalf of these modules by altering the entity info. Logically, UUID should then implement the schema counterparts to those implementations by altering the schema. IMHO, I think this is beautifully done.So yes, this is guaranteed to work since UUID is implemented on behalf of core at the right levels in both the entity info and schema.
P.S. By the way, don't you meanPlease ignore this.module_exists('file_entity')
instead ofmodule_exists('file')
?Comment #28
bendiy CreditAttribution: bendiy commentedWill you need to add 'uuid_schema_generate()' for each module that uses UUID? So if I'm using node_export, I'd have to add the following to the patch in #26?
Is there any way to generate those calls from installed modules that require UUID?
Comment #29
skwashd CreditAttribution: skwashd commented#26 this doesn't support all entities, it assumes that we only support core entities.
#28 if node_export uses entities, then it should "just work"
Comment #30
Refineo CreditAttribution: Refineo commentedsubscribe
Comment #31
dixon_Thanks everyone for working on this. It's a tricky problem, and I really appreciate the time put into this. Thanks. I'll take a close look at this in the close future.
A very quick review on patch from #17 (which seems like a reasonable approach) only reveals one very minor issue. I want all patches to keep "core standard", so I'm a little bit picky :)
The comments should en with "."
Comment #32
zhangtaihao CreditAttribution: zhangtaihao commentedSo wait, are we actually using #17? Or are we going to wait for http://drupal.org/node/1290986 to be resolved first?
Also, I'm concerned about the implications of using the
drupal_static_reset('entity_get_info')
approach in the bigger picture. Does it now mean that entity info could potentially be rebuilt a ridiculous number of times?P.S. Resetting the static cache can be done since Drupal 7.0, so no core dependency there (apart from the Drupal 7.2 in the Entity API).
EDIT: @dixon_, If we are going ahead with #17, let me know and I'll be happy to reroll #17 with your suggestions.
Comment #33
zhangtaihao CreditAttribution: zhangtaihao commentedNote that my patch in #17 will require Drupal 7.9 (not yet released as of now) due to the fix in #1289364: SchemaCache generates empty cid.
EDIT:
The problem is basically that the schema cache never included fields from UUID alterations (perhaps others, too). With that fix, the cached schema now has UUID fields, though entity info still hasn't got them yet. Will investigate in ~10 hours (after sleep & meeting).
EDIT2:
Another thing I've noticed is that the schema is actually rebuilt only once. The reason is that
drupal_get_complete_schema()
statically caches the schema and doesn't expose a facility for resetting its static cache. So, unless there is no other module implementing any schema tables (which is impossible),uuid_schema_alter()
will NOT run itself twice.Still keeping the the recursion check, just in case. I will investigate the aforementioned issue and follow up with a cleaned patch.
Comment #34
zhangtaihao CreditAttribution: zhangtaihao commentedIt turns out that
entity_get_info()
kept the stale schema fields even after UUID alterations. The fix was to reset the static and persistent cache again after the call toentity_get_info()
so that entity info gets built strictly after the schema has been built and cached.Patch attached. I've rolled it against the latest HEAD (577be51) and thus the latest commit to uuid.install (e5daf00).
Comment #35
zhangtaihao CreditAttribution: zhangtaihao commentedAlright, it hasn't worked. The entity info is now blank.
EDIT: Specifically, entities like 'rules_config' seem to get NULL.
Comment #36
zhangtaihao CreditAttribution: zhangtaihao commentedI am at a loss. The UUID alteration getting entity info causes the entity info to cache stale fields. Clearing the entity info cache screws up initiating calls to
entity_get_info()
because where they expect a return we've just cleared it.Anyone?
Comment #37
dixon_Hmm, this is a hard nut to crack... But thanks @zhangtaiho for the debugging of this! As you saw, I already committed #17 with some modification, in a first attempt to solve it. Obviously that wasn't enough, as you mention. I'm going to read through your analysis in more detail soon.
Comment #38
mh86 CreditAttribution: mh86 commentedI updated my modules (Entity API, Field collections, OG, Profile2, Message) to the latest dev versions, reverted UUID to a version before #17 was committed, and enabling UUID worked :) Seems like #1290986: avoid entity_load() during entity info cache rebuilds helps a lot.
Comment #39
glennpratt CreditAttribution: glennpratt commentedUUID worked occasionally before #17, after it doesn't work at all. Trying to debug, but thought I'd share early.
EDIT: uuid column *is* on core entity tables, but not in Drupal schema and UUID doesn't generate or write UUIDs.
D7.8, Rules, OG, Commerce and several others.
Comment #40
zhangtaihao CreditAttribution: zhangtaihao commented@glennpratt:
This issue has to do with my comment in #33 and the first part of #34. I seem to be able to rebuild the correct schema with that Drupal 7 core fix by checking
drupal_get_schema()
and seeing if the UUID field exists. It's just the entity info that doesn't pick up 'uuid' in schema_fields_sql.@mh86:
I concur. Using the previous code works.
I'm actually inclined to go back to that code. However, there's a sticky issue. The whole reason we can't use
entity_get_info()
is that it will try to build the schema, at which point entity info will end up with a stale schema for schema_fields_sql. Looking from the workings ofentity_get_info()
, though,hook_entity_info_alter()
is invoked with the presumed existence of 'schema_fields_sql'. I'm not sure manually invoking the hook (even with the default values manually added and assuming core doesn't add additional bits in future updates) will not incur the wrath of some module implementinghook_entity_info_alter()
expecting information as described inentity_get_info()
before altering.An alternative approach (which we'd be stuck with even if we use the stale
entity_get_info()
) is to manually set 'schema_fields_sql' to the stale fields so that other modules could get what they'd be expecting without UUID anyway. Modifying @claudiu.cristea's patch in #12, I've attached an example of what can be done to get around the problem (rolled against HEAD). Again, this is dependent on core updates to theentity_get_info()
building logic that we'd then have to roll into this one.This approach has the advantage of completely bypassing the
entity_get_info()
workflow. Since we can agree on a contract forhook_entity_info_alter()
not to use entity info using the function (e.g. by loading an entity), we can then safely say there is no dependency on theentity_get_info()
function.All that's left now is for
entity_get_info()
to fail on recursion more gracefully.Comment #41
glennpratt CreditAttribution: glennpratt commentedLatest dev + #40 + the core patch mentioned seems to work for me so far. Nice work.
Do see some errors on
drush cc all
might be related.Comment #42
zhangtaihao CreditAttribution: zhangtaihao commentedThanks.
Regarding the warnings, may I assume you've updated Profile2, OG, and Field collection (and flushed the caches several times), wherever applicable? It could also be some other module doing something in their
hook_entity_info_alter()
that didn't get revealed until #40.I've also encountered this problem in one of my early attempts at implementing my own entity type. I specified the wrong value for 'bundles' and it triggered similar warnings.
Then again, maybe it's something wrong with my patch. Perhaps these are the unforeseen side effects of manually building entity info. Please let me know how you go with your modules list.
Comment #43
glennpratt CreditAttribution: glennpratt commentedQuite right about OG, I forgot that one, warnings are gone now.
Believe this is the OG commit for those looking:
http://drupalcode.org/project/og.git/commit/9a416a2a3b7f3029eaa208c92b8f...
Comment #44
zhangtaihao CreditAttribution: zhangtaihao commentedSince nothing seems to be happening (or breaking), I'm going to tentatively mark this as RTBC (#40). Note that the patch has the following requirements so that it doesn't crash the site:
Also, it requires Drupal 7.9 for any UUID to be loaded at all.
Please change the status back to "needs work" if anyone thinks we need an alternative (and could possibly come up with one).
Comment #45
zhangtaihao CreditAttribution: zhangtaihao commentedRight, so Drupal 7.9 has been released. What happens now?
Comment #46
mh86 CreditAttribution: mh86 commentedUnfortunately I still encounter some problems when activating the profile2 or message module and having uuid already installed:
PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'drupal.profile_type' doesn't exist: SELECT p.* FROM {profile_type} p
This happens with and without the patch from #40.
Comment #47
dixon_Thanks you guys for all the work on this one! I will take a look at the patch in #40 later this week and hopefully commit it.
Comment #48
zhangtaihao CreditAttribution: zhangtaihao commented@mh86: Over the course of the past week I've been trying all combinations of on/off for the modules you described. I've tried all sorts of order in which I enable, disable, and uninstall modules. I still haven't come across the problem.
On a slightly unrelated note, I've come across a curious thing recently. I've removed a site and re-installed it (to test the installation of those modules on a fresh install) and found it trying to look at the old entity info + schema + fields. I found out that it was because I had it running on the same domain name and the memcached server my platform was hardcoded for tried to serve the old entries. Of course it failed, so I restarted the memcached server and it worked again. I was wondering whether a vague variant of this problem might be happening for you.
Comment #49
dixon_I've been thinking some more on this, specially since I ran into the problem again in another context.....
We simply can't call
entity_get_info()
duringhook_schema_alter()
. We have to let all modules generate/alter the schema in peace before doing anything with entity info. Callingentity_get_info()
before schema cache is set will unconditionally result in incomplete schema caches (which is the current state in UUID module and probably causes a lot of problems that might seem unrelated to UUID).So, I think these are the only solutions to it:
1. We can only alter the schema if the entity info cache exists (because re-generating it during
hook_schema_alter
doesn't work). If the entity info cache doesn't exist, we can't alter the schema. Period. We have to postpone that process to a later stage when the entity info cache exists (maybe with a shutdown callback).2. Maybe it could work to re-generate entity info cache in
hook_schema_alter()
if UUID module is the last module to alter all schemas. The schema cache is dynamically built/set by DrupalCacheArray, so it might work...I'll try some of my theories very soon...
Comment #50
pineray CreditAttribution: pineray commentedBelow code in the function uuid_schema_alter may break hook_schema_alter in other module.
For instance, when uuid and i18n_taxonomy are enabled, i18n_taxonomy.module doesn't work appropriately.
Comment #51
zhangtaihao CreditAttribution: zhangtaihao commentedWell, the latest incarnation of the fix is in #40. The branch hasn't been updated since #17. With #40, I am able to deploy terms with features.
Comment #52
dixon_This should now be fixed in 7.x-1.x-dev and the alpha3 release that I'm rolling right now. Read the upcoming release announcement for more info.
Comment #53
ronnienorwood CreditAttribution: ronnienorwood commentedIs this error related to this thread or should I crank up a new issue ?? Getting this after update to alpha3 from alpha1 when clicking on either 'front page' or 'administration pages' link.
PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'base.uuid' in 'field list': SELECT base.uid AS uid, base.name AS name, base.pass AS pass, base.mail AS mail, base.theme AS theme, base.signature AS signature, base.signature_format AS signature_format, base.created AS created, base.access AS access, base.login AS login, base.status AS status, base.timezone AS timezone, base.language AS language, base.picture AS picture, base.init AS init, base.data AS data, base.uuid AS uuid FROM {users} base WHERE (base.uid IN (:db_condition_placeholder_0)) ; Array ( [:db_condition_placeholder_0] => 1 ) in DrupalDefaultEntityController->load() (line 196 of /home/(owner)/(root)/includes/entity.inc).
Comment #54
dixon_@ronnienorwood It seems some strage have happended to your installation, as did with many installations on aplha1 and alpha2.
If it's possible, try to completely uninstall UUID and then re-install with alpha3. But be aware, you'll have to re-generate all UUID, so they will change!.
If the problem persists, please open up a new issue since it's not fully releated to the original issue here.
Comment #55
ronnienorwood CreditAttribution: ronnienorwood commented@dixon_ thanks I got it to work by doing the uninstall but it would not work unless I kept uuid disabled until I could get the new version in so I had to install the alpha3 version manually through the file system since the module update in d7 does not list modules that are disabled.
Comment #57
BartGysens CreditAttribution: BartGysens commentedWhat a mess using this thing UUID!
Several errors keep coming one after the other; always telling me same column with *uuid* is missing, from {user} to {node} by now...
Trying to refresh through git hopefully works...
Put a big red label on this one please!