Forum: Bug Report and Feature Requests

Odd items in my history

solitude 🚫

(following on from another thread) I've been looking at the 'more info' ofsome of the older items in my history, and some seem completely unfamiliar: authors I do not recognise, stories with descriptions and tags that trigger squicks. Is it possible that such stories are a case of ID reuse: the story I actually read has been deleted, the id assigned to a story added shortly after - so the reference in my history is a lie? If so, is there any way of getting all such mismatches removed from people's histories, please? Also, is a vote I gave to the old story mow assigned to the new one? If so, I think that also needs correcting!

(Primary key reuse is liable to cause a whole slew of problems, unless every cross reference between tables is properly marked as a foreign key - and the dbms enforces referential integrity. Cascaded deletes can help with maintenance, if supported by the dbms.)

Replies: Pixy madnige Lazeez Jiddan (Webmaster)

Pixy 🚫

@solitude

Could it be that you have read those stories in response to discussions about them on the forums, rather than through personal desire?

Replies: solitude

solitude 🚫

@Pixy

Could it be that you have read those stories in response to discussions about them on the forums, rather than through personal desire?

Possibly. But I don't vote on a story that I accidentally visit - and the unrecognised stories have a vote recorded.

(It would be nice if story links in the forums were automatically adjusted to point at the 'more info' page, so we can look at the description, score, tags etc without the story immediately appearing in our histories (or counting against our daily quotas. But only if the link doesn't point to the wrong place if the story is deleted!)

madnige 🚫

@solitude

looking at the 'more info'

The [More Info] link is only keyed on the (re-useable) story-id, so if you feed it a deleted story's ID it's quite possible you'll get back info on a more recently posted story. The database key also uses the 'shortform' story title (like appears in the URL), but I can't remember if LJ said anything else was used as well - possibly a timestamp to differentiate revisions.

Lazeez Jiddan (Webmaster)
Updated:

@solitude

Primary key reuse is liable to cause a whole slew of problems, unless every cross reference between tables is properly marked as a foreign key - and the dbms enforces referential integrity. Cascaded deletes can help with maintenance, if supported by the dbms.

The stories table is properly linked by foreign keys to the read stories table and other related tables. So whenever a story is deleted, all the data, from bookmarks, to text, to read flags, to votes, etc... MySQL cleans up after it.

I use belt AND suspenders in this case and the function that deletes a story scours the database for any possible remnants.

Also, stories have a double key, so hitting /s/12345/some-story, is not the same as hitting /s/12345/some-other-story.

I use a two-prong strategy for story text. I have the text saved in a file hierarchy as files and in the database as data rows. Due to the use of a file hierarchy, using the author's id and the story's id, I prefer not to leave gaps in the story id key and the author id key.

For those stories to be in your read list, you must have clicked on them at some point.

One remote possibility is that you share your account with somebody else and they have clicked them.

Forum: Bug Report and Feature Requests

Odd items in my history

WARNING! ADULT CONTENT...