Hi, running into strange behavior with this module and hope somebody can't point me in the write direction.

I'm updating a 5x site to Drupal 6. The 5x site was using buddylist. I took the following steps:

1. Install User Relationships on the 5x site
2. Run the buddylist migration module (the relationship type I created for the migration was "friend" and I specified that it had to be a 2 way relationship)
3. Uninstall buddylist
4. Upgrade the site (including User Relationships) to 6x

I'm getting some strange behaviors , for example:

- Relationship requests can get made, but when the requestee clicks on the button to approve the relationship, the pending relationship page is reloaded, and a user message stating that the users "friend request has been approved". However the relationship shows up as still pending. And if I look at the database, the relationship is not marked as approved (approved = 0).
- Another strange thing that sometimes happens. Say the user has a friend request from user 1. The user clicks on the "approve" link on that friend request, but the text in the javascript pop-up says "Are you sure you want to approve the friend relationship request from user2?" It should say user1, not user2.

Thinking perhaps data was corrupted in the buddylist -> UR migration, I looked in the database for clues. Some things I have seen, but don't know if they are problems or not:

- Almost all the migrated relationships have 2 rows in the user_relationships table. The 2 rows have all the same data, including rid, the only difference being that the requestee and requestor switch positions in the second row.
- New relationship requests that have not been approved are created with rid = 0, so that various rows exist in the table with rid =0.

If somebody who knows the internals of this module could comment on whether these are problems with the database, and perhaps steer me towards possible causes of the problem, I'd appreciate it very much.

Cheers,

Steve

Comments

sja1’s picture

sja1 commented

um, I meant to say "CAN point me in the RIGHT direction", not "can't point me in the write direction". These are the moments when you wish nodes and not just comments could be edited after the fact!

sja1’s picture

sja1 commented
Title: Can't accept relationship requests » rid not created properly as an AUTO_INCREMENT column - breaks the module
Category: support » bug

I think I found the problem. For some reason in the upgrade from Drupal 5 to Drupal 6, the rid column was not set to auto increment (I am using php 5.2.8 and mysql 5.0.45). As a check, I did a clean install of Drupal 6 and User Relationships on a different computer, and in that table also the rid column was not set to auto increment (php 5.2.6, mysql 5.0.5).

Because of this, all new relationship requests were being stored in the database with rid = 0. This appears to break the module, resulting in unexpected and erroneous behavior.

I then looked at the user_relationships_api.install file, and saw that both in the schema definition, and in the hook_update implementation that the rid column is defined as a "serial" data type. Looking up serial in the mysql documention it says

SERIAL is an alias for BIGINT UNSIGNED NOT NULL AUTO_INCREMENT UNIQUE.

Looking back at the column that had been created in my database, I saw that not only was it not auto_increment, it was int instead of bigint, and was not unique. This last discrepancy seems necessary because it appears that 2 way relationships are stored in the column as 2 separate rows with a shared rid.

So maybe there is a problem with the way SERIAL is used in the install file. In my case the column wasn't defined as serial. And even if it had been created properly, would the UNIQUE characteristic have broken the 2 way relationship functionality?

Can anybody else replicate this?

alex.k’s picture

alex.k commented
Issue tags: +rc3block

Will try to clean up 5->6 migration issues.

alex.k’s picture

alex.k commented
Status: Active » Closed (duplicate)

Just re-tried the upgrade process, and the column was converted to autoincrement correctly. The latest -dev release of both 5.x and 6.x are required, and the trick is to enable the "UR Upgrade Assistant" module in 5.x before the upgrade. The solution had been implemented earlier for #575506: Error message during upgrade 5.x-2.x.dev to 6.x-1.0-rc2. Will be part of the next release for both 5 and 6.