The field operation of the {userpoints_txn} table get a different name in the table for PostgreSQL.

Comments

avpaderno’s picture

Priority: Normal » Critical
avpaderno’s picture

Title: Table field get inconsistently called » Table field get inconsistently named
jredding’s picture

Priority: Critical » Normal
Status: Active » Postponed (maintainer needs more info)

I just checked version 3.5 and postgres and mysql are getting the same fields so I'm confused as to what you're referring to.

avpaderno’s picture

Status: Postponed (maintainer needs more info) » Active

It doesn't seem so to me.
In userpoints.module I find the following code:

    case 'pgsql':
      db_query("CREATE TABLE {userpoints} (
          uid           SERIAL,
	        points        INTEGER NOT NULL default '0',
	        max_points    INTEGER NOT NULL default '0',
	        last_update   INTEGER NOT NULL default '0',
	        PRIMARY KEY (uid)
        );");
      db_query("CREATE TABLE {userpoints_txn} (
          txn_id        SERIAL,
	        uid           INTEGER NOT NULL default '0',
	        approver_uid  INTEGER NOT NULL default '0',
	        points        INTEGER NOT NULL default '0',
	        time_stamp    INTEGER NOT NULL default '0',
	        status        INTEGER NOT NULL default '0',
	        event         VARCHAR,
	        description   VARCHAR,
          expirydate    INTEGER NOT NULL default '0',
          expired       BOOLEAN, 
          parent_txn_id INTEGER NOT NULL default '0'
	        PRIMARY KEY (txn_id)
	      );");
      break;

which is different from:

    case 'mysql':
    case 'mysqli':
      db_query("CREATE TABLE {userpoints} (
          uid           INT(10) NOT NULL DEFAULT '0',
          points        INT(10) NOT NULL DEFAULT '0',
          max_points    INT(10) NOT NULL DEFAULT '0',
          last_update   INT(11) NOT NULL DEFAULT '0',
          tid           INT(11) NOT NULL default '0',
          pid           INT(11) NOT NULL auto_increment,
          PRIMARY KEY (pid),
          KEY (last_update)
        ) /*!40100 DEFAULT CHARACTER SET utf8 */;");
      db_query("CREATE TABLE {userpoints_txn} (
          txn_id        INT     NOT NULL AUTO_INCREMENT,
          uid           INT(10) NOT NULL DEFAULT '0',
          approver_uid  INT(10) NOT NULL DEFAULT '0',
          points        INT(10) NOT NULL DEFAULT '0',
          time_stamp    INT(11) NOT NULL DEFAULT '0',
          status        INT(1) NOT NULL DEFAULT '0',
          description   TEXT,
          reference     varchar(128),
          expirydate    int(11) NULL default '0',
          expired       tinyint (1) NOT NULL default '0',
          parent_txn_id int(11) NOT NULL default '0',
          tid           INT(11) NOT NULL default '0',
          entity_id     INT(11) default NULL, 
          entity_type   varchar(32) default NULL, 
          operation         VARCHAR(32),
          PRIMARY KEY (txn_id),
          KEY (operation),
          KEY (reference),
          KEY (status)
        ) /*!40100 DEFAULT CHARACTER SET utf8 */;");
      break;
kbahey’s picture

Version: 5.x-3.5 » 5.x-3.x-dev
Status: Active » Fixed

Wait for 24 hours, then download the 5.x-3.x-dev tarball.

The commits for this are here:

http://drupal.org/cvs?commit=118847
http://drupal.org/cvs?commit=117311

jredding’s picture

Version: 5.x-3.x-dev » 5.x-3.5

First you don't find that code in userpoints.module, as it doesn't exist and has never existed there. its located in userpoints.install.

Second you're correct the changes the stable version on d.o does not contain these changes. They were checked in on May 22nd (to sync Postgres) but a stable version hasn't been created for that... yet.

so.. the solution is to pull the DEV or CVS.

avpaderno’s picture

Actually, there isn't a way to select which file the issue is between a '.module' file, and a '.install' file.
I think it has been better to select "Code: userpoint API" than "Other".

jredding’s picture

no worries I was just referring to your message.

Thanks for bringing up the problem, it should be fixed now.

Anonymous’s picture

Status: Fixed » Closed (fixed)

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