Is the Location table missing the 'lid' field?

But I don't understand how it could have ever worked. People have been using it for a while, though...

...just resetting the title for this issue...

The last location update requires a schema update. You need to run update.php

I just installed location 4.7 clean and have the same problem.

From the location.install file:

function location_install() {
  drupal_set_message('Installing location');
  switch ($GLOBALS['db_type']) {
    case 'mysql':
    case 'mysqli':
      db_query("
      CREATE TABLE {location} (
        eid int unsigned NOT NULL default '0',
        type varchar(6) NOT NULL default '',
        name varchar(255) default NULL,
        street varchar(255) default NULL,
        additional varchar(255) default NULL,
        city varchar(255) default NULL,
        province varchar(16) default NULL,
        postal_code varchar(16) default NULL,
        country char(2) default NULL,
        latitude decimal(10,6) default NULL,
        longitude decimal(10,6) default NULL,
        source tinyint default '0',
        PRIMARY KEY  (type,eid)
      ) /*!40100 DEFAULT CHARACTER SET utf8 */;
      ");
...

The lid field is added in the update functions but not in the install function. So you have to run update right after you originally install. :)

I have to say there's something screwy going on here. I've tried installing per instructions and no luck, then installing without importing .mysql files first and still no luck. Tried importing .mysql files then upgrading and no luck. This is exactly what I hate about using drupal.

location.mysql (the manual says to use this one)
oid int(10) unsigned NOT NULL default '0',

ocation.install
eid int unsigned NOT NULL default '0',

from the location.upgrade.php
db_query("ALTER TABLE {location_node} CHANGE nid oid int(10) unsigned NOT NULL default '0'");

to make matters worse, it appears lid and and eid are both being treated as primary key getting the same data.

It looks like the update_4 changes haven't been added to the install script.

The workaround is to run update 4. This seems to resolve it.

Also it seems that if you're using PostgreSQL the update fails silently.

Comment #6 has it right. I forgot to update the location_install() function when I updated the schema. I added a location_update_4() function, but forgot to reflect those changes in location_install(). This basically means that people that are just installing the module for the first time (after the most recent update) are gonna have problems. People who have run the update will be fine. In anycase, I will post a patch here shortly (in the next few hours) with instructions for those of you who just installed the module recently and got these 'lid' errors.

Sorry for the inconvenience.

-Ankur

Thanks, waitin for the update.

Ok. So this is the patch I'm supposin' to commit, but I do need someone familiar w/ PostgreSQL to verify my syntax, either with your super accurate attention to detail that doesn't require testing, or w/ your PostgreSQL database server through testing both the install function and the update from schema version 3 thru schema version 5.

As for people running this on mysql, it has been tested on mysql. So you can either apply this patch immediately, or you can wait til the pgsql is verified and the patch is committed.

In either case, for those of you that just installed location module on mysql and are having the problem w/ the missing lid column, you will need to delete every sign of the location module from your database before re-enabling it in your admin/modules section. To this end, I recommend running the following queries in your database (hopefully, you can run these via command-line or something like PhpMyAdmin):

DROP TABLE location;
DROP TABLE zipcodes;
DELETE FROM sequences WHERE name = 'location_lid';
DELETE FROM system WHERE name = 'location' and type = 'module';
DELETE FROM cache;

If you are using a database prefix and this prefix, for example, is the string 'prefix_', then the queries would be:

DROP TABLE prefix_location;
DROP TABLE prefix_zipcodes;
DELETE FROM prefix_sequences WHERE name = 'prefix_location_lid';
DELETE FROM prefix_system WHERE name = 'location' and type = 'module';
DELETE FROM prefix_cache;

Again, I apologize for the major inconvenience. I'd made notes to myself to do the pgsql and to update the location_install() function, but completely forgot about them when came the late-night commit to the CVS.

Hi all,

I've updated the patch to be correct for PostgreSQL. I've also taken liberty to make the following alterations:

• Removed the (N) suffixes to integer types in MySQL CREATE TABLE and ALTER TABLE statements. As mentioned previously these are useless and are no longer used in Drupal as of Drupal 5. Might as well modify your 4.7 code to suit so you don't have useless bytes.
• Removed explicit modification of the sequences table in the location_install() function. This is not only unneccessary but also breaks PostgreSQL because that table doesn't exist.
• Modified the PostgreSQL update to use a different method of adding the column. Normally columns are added using db_add_column(). In this case it cannot be done because the column type is serial. Rather than adding an integer column then populating that column using a PHP loop over all records in the location table i've chosen to create a new table (1 query) and populate it using INSERT INTO ... SELECT ... (also 1 query). This has the side benefit of automatically incrementing the sequence created by the serial type automatically. Also there is less effort required by PHP and as a result I'd say this will run faster (zero context switches etc).

Here is the patch. I've tested it on PostgreSQL and it works ok without any records in the location table. I'm pretty sure it'll work with records. :)

--
Sammy Spets
Synerger
http://synerger.com

Thanks for the patch. This has been committed to DRUPAL-4-7 and HEAD.