I'm getting the following error on table creation when I try to enable the module in one of my environments: http://pastebin.com/e5K9BM6q

The other environments don't exhibit this behavior.. so I've opted for labeling it "support request" over "bug".

I think this is relevant to the problem: http://stackoverflow.com/questions/1814532/1071-specified-key-was-too-lo...

I noticed that hook_schema() doesn't explicitly declare a primary key.. I'm not sure if that's necessarily the problem, but I think it's clearly choking on the size of the user agent string index.. and that composite index is the only thing that looks like a primary key.

If I'm not mistaken, and mysql really is trying to use the tuple (uid, hostname, user_agent) for its primary key, isn't this bound to run into collisions?

Comments

star-szr’s picture

star-szr
he/him
Primary language English
CreditAttribution: star-szr commented

We had a related report over at #1825020: Remove sorting on user agent column and remove the index from the login_history table. I'm not sure why the index combines uid, hostname, and user_agent, I wasn't around during the development of this module. Any suggestions?

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
CreditAttribution: greggles commented

I think originally the module had a query on all three of three fields (or I intended it to) and that's why they are in an index. I'm not sure why there's no primary key.

Those three fields are not unique, but that's OK for indexes (it would be a problem for unique keys or primary keys).

Seems fine to me to remove that index.

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
CreditAttribution: greggles at CARD.com commented
Issue summary: View changes
Status: Active » Closed (duplicate)

It seems likely this is actually just a duplicate of that, so closing. Please reopen if this is an ongoing issue.