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

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Kristjan Logason’s picture

Have you looke at this. http://drupal.org/node/1256888 it just saved me

wusel’s picture

Title: Crash after enabling UUID » crash direct after I have enabled "uuid"
Version: 7.x-1.x-dev » 7.x-1.0-alpha2

It 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

mh86’s picture

claudiu.cristea’s picture

Title: crash direct after I have enabled "uuid" » Crash after enabling UUID
Version: 7.x-1.0-alpha2 » 7.x-1.x-dev
claudiu.cristea’s picture

Title: crash direct after I have enabled "uuid" » Crash after enabling UUID
Version: 7.x-1.0-alpha2 » 7.x-1.x-dev
FileSize
8.88 KB

Same here. Attached you can find a debug backtrace made with XDEBUG.

claudiu.cristea’s picture

[Mon Sep 05 10:13:11 2011] [error] [client 88.121.76.87] PHP  20. uuid_schema_alter() /var/www/html/includes/module.inc:1004

This seem to be the source of bug. I cannot figure out exactly what is causing.

/**
 * Implements of hook_schema_alter().
 */
function uuid_schema_alter(&$schema = array()) {
  // We aren't calling entity_get_info() directly here becase it's caching too
  // hard and can't be used inside hook_schema_alter(). Also, we are only using
  // a fraction of what we original logic fetches and we don't need the fancy
  // logic for default values since it's a prerequsite that
  // $info['entity keys']['uuid'] is set for the alteration to kick in.
  $entity_info = module_invoke_all('entity_info');
  drupal_alter('entity_info', $entity_info);

  foreach ($entity_info as $entity_type => $info) {
    if (isset($info['uuid']) && $info['uuid'] == TRUE && !empty($info['entity keys']['uuid'])) {
      // Add the Universally Unique Identifier column to the definition.
      uuid_schema_generate($schema, $info['base table'], $info['entity keys']['uuid']);
      if (!empty($info['revision table']) && !empty($info['entity keys']['revision uuid'])) {
        // Add the Universally Unique Version Identifier to the definition.
        uuid_schema_generate($schema, $info['revision table'], $info['entity keys']['revision uuid']);
      }
    }
  }
}
mh86’s picture

For 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.

claudiu.cristea’s picture

The bug is caused by uuid_schema_alter(), more precise by drupal_alter():

drupal_alter('entity_info', $entity_info);

Do you have Profile2 installed? Because it seems to me that this is triggered by profile2_entity_info_alter().

wusel’s picture

#8:

Yes, I have installed Profile2.

skwashd’s picture

Thanks for the additional info. I'm on the road for most of this week, but I'll try to get this sorted ASAP.

claudiu.cristea’s picture

Assigned: Unassigned » claudiu.cristea
Status: Active » Needs review
FileSize
1 KB
  // We aren't calling entity_get_info() directly here becase it's caching too
  // hard and can't be used inside hook_schema_alter(). Also, we are only using
  // a fraction of what we original logic fetches and we don't need the fancy
  // logic for default values since it's a prerequsite that
  // $info['entity keys']['uuid'] is set for the alteration to kick in.

This 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 from entity_get_info() is causing the bug. This happens in hook_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 if hook_entity_info() doesn't set the 'bundles' key, this is supplied in entity_get_info() by adding an empty 'bundles' key.

$entity_info[$name] += array(
  ...,
  'bundles' => array(),
  ...,
);

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:

$entity_info = module_invoke_all('entity_info');
drupal_alter('entity_info', $entity_info);

with the complete...

$entity_info = entity_get_info();

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.

claudiu.cristea’s picture

FileSize
3.87 KB

The 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.

zhangtaihao’s picture

Interestingly, 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.

zhangtaihao’s picture

Status: Needs review » Needs work

I'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.

zhangtaihao’s picture

We'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 calls drupal_get_schema() (and in turn invokes hook_schema_alter()). This means that, inevitably, by the time uuid_schema_alter() is invoked the entity_get_info() will have begun - unless, of course, there's nothing calling entity_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.

zhangtaihao’s picture

I'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 hits drupal_schema_fields_sql() and soon uuid_schema_alter(), preventing entity info other than the basic from being returned and thus precluding uuid_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 to drupal_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:

drupal_static_reset('entity_get_info');

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.

zhangtaihao’s picture

Assigned: claudiu.cristea » zhangtaihao
Status: Needs work » Needs review
FileSize
2.28 KB

IT 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 in uuid_schema_alter() and set around the call to entity_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 implementing hook_schema_alter() could potentially change something twice. But because they really shouldn't, I think it's a reasonably safe assumption that hook_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 for uuid_schema_generate(). I've had no such luck, because any module that implements hook_entity_info_alter() with a call to entity_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.

mh86’s picture

I 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.

zhangtaihao’s picture

Using 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.

zhangtaihao’s picture

Assigned: zhangtaihao » Unassigned
bennos’s picture

subscribing

bendiy’s picture

sub.
Breaks Profile2 install:
http://drupal.org/node/1260644

bendiy’s picture

I tested patch in #17 and it does fix the install issue with Profile2.

mh86’s picture

I 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.

zhangtaihao’s picture

I'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.

mh86’s picture

FileSize
1.77 KB

I 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.

zhangtaihao’s picture

I 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 mean module_exists('file_entity') instead of module_exists('file')? Please ignore this.

bendiy’s picture

Will 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?

if (module_exists('node_export')) {
  uuid_schema_generate($schema, 'node_export', 'uuid');
}

Is there any way to generate those calls from installed modules that require UUID?

skwashd’s picture

Status: Needs review » Needs work

#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"

Refineo’s picture

subscribe

dixon_’s picture

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 :)

+++ b/uuid.install
@@ -14,21 +14,30 @@ module_load_include('inc', 'uuid', 'uuid.schema');
+    // Prevent recursion
+    $altering = TRUE;
+
+    // Force rebuilding
+    drupal_static_reset('entity_get_info');

The comments should en with "."

zhangtaihao’s picture

So 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.

zhangtaihao’s picture

Note 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.

zhangtaihao’s picture

Status: Needs work » Needs review
FileSize
618 bytes

It 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 to entity_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).

zhangtaihao’s picture

Alright, it hasn't worked. The entity info is now blank.

EDIT: Specifically, entities like 'rules_config' seem to get NULL.

zhangtaihao’s picture

I 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?

dixon_’s picture

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.

mh86’s picture

I 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.

glennpratt’s picture

UUID 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.

zhangtaihao’s picture

@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 of entity_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 implementing hook_entity_info_alter() expecting information as described in entity_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 the entity_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 for hook_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 the entity_get_info() function.

All that's left now is for entity_get_info() to fail on recursion more gracefully.

glennpratt’s picture

Latest 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.

± |sso ✗| → drush cc all
Invalid argument supplied for foreach() field.info.inc:215                                                               [warning]
Invalid argument supplied for foreach() field.info.inc:215                                                               [warning]
Invalid argument supplied for foreach() field.info.inc:215                                                               [warning]
Invalid argument supplied for foreach() field.info.inc:215                                                               [warning]
array_keys() expects parameter 1 to be array, null given field.info.inc:306      [warning]
array_merge(): Argument #2 is not an array field.info.inc:306                    [warning]
Invalid argument supplied for foreach() field.module:661                                                               [warning]
Invalid argument supplied for foreach() field.info.inc:308                                                               [warning]

'all' cache was cleared                                                          [success]

 
zhangtaihao’s picture

Thanks.

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.

glennpratt’s picture

Quite 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...

zhangtaihao’s picture

Status: Needs review » Reviewed & tested by the community

Since 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:

  • Latest dev version of Profile2 (wherever installed)
  • Latest dev version of OG (wherever installed)
  • Latest dev version of Field collection (wherever installed)

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).

zhangtaihao’s picture

Right, so Drupal 7.9 has been released. What happens now?

mh86’s picture

Status: Reviewed & tested by the community » Needs work

Unfortunately 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.

dixon_’s picture

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.

zhangtaihao’s picture

@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.

dixon_’s picture

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() during hook_schema_alter(). We have to let all modules generate/alter the schema in peace before doing anything with entity info. Calling entity_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...

pineray’s picture

Below code in the function uuid_schema_alter may break hook_schema_alter in other module.

    // Force rebuilding.
    drupal_static_reset('entity_get_info');

For instance, when uuid and i18n_taxonomy are enabled, i18n_taxonomy.module doesn't work appropriately.

zhangtaihao’s picture

Well, 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.

dixon_’s picture

Status: Needs work » Fixed

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.

ronnienorwood’s picture

Is 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).

dixon_’s picture

@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.

ronnienorwood’s picture

@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.

Status: Fixed » Closed (fixed)

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

BartGysens’s picture

What 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!