Azure Jane Lunatic (Azz) 🌺 (![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
azurelunatic) wrote2007-06-09 02:36 pm
azurelunatic) wrote2007-06-09 02:36 pm
Entry tags:
Tags!
As you may have noticed, LiveJournal's limit on the number of entries that can be displayed in the /tag/foo view is now 1,000. It was 100 for a long time, and prior to that, it was something that now seems very extremely limited. Most people don't have to worry about having hit previous tag limits, because they don't post as insanely often as I do, so this whole post is going to be irrelevant to a lot of my readers.
When this change was announced in![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-community.gif)
lj_releases, the number one question I saw about this was: "So, I've got about 300 entries tagged 'bar', but I can't see them in /tag/bar; I can only see 100 -- what's wrong?" One of the things that was stressed in the lj_releases post was the concept from this point on, which was what a lot of people with this question weren't picking up on, or weren't fully understanding.
If you haven't figured out how LJ's tag system works, this is completely confusing. The entries in the tag view are not searched out each and every time someone wants to look at a tag. They're modified if and only if someone saves a change to a tag. (![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
afuna demonstrated to me that merely opening an entry in tag edit mode and saving no-changes, or saving a change to a different tag on the same entry did not actually create a change in back entries of the specified tag that had fallen off the end of the tag-view, and now that I've thought about it for a while, I see why.)
The tag view acts like it's the result of a list of entries possessing that specified tag. It displays sorted in chronological order by the displayed date on the entry (something that was posted in 2002 and wasbackdated dated out of order to 1995 is going to display with the rest of the 1995 entries). Imagine that LJ has a very tiny three-ring binder, one that can only fit 10 (or 11, if you stuff the binder to the point where it's going to explode) tiny little pages, and each page can hold the address of only 10 of your journal entries. Each time you write down someone's name in your Note make an entry with that tag or edit an entry to have that tag, LJ writes down the link to your entry in the next empty space in the very tiny binder with that tag's name on it. If you have under 100 entries tagged with that tag, they're all going to be in that tiny binder.
But when you hit 100 entries, the little tiny binder starts getting uncomfortably crowded. (In actual practice, there's generally an 11th page*, but once that 11th page is full, there is No. More. Room.) At this point LJ flips back through the binder to the first page, rips the first page out and tosses it in the shredder and watches the shredded remains burn to ash, and sticks a new blank page in the back of the binder, and continues to faithfully record all the times entries are tagged in the new slots. There is nowhere that the locations of the old entries are stored as far as the tag view is concerned. (The analogy breaks down badly when you delete a tag from an entry in the middle; instead of crossing-through, it would have to white-out it over, and move all the entries up a line. Massive waste of correction tape & a whole lot of work.)
But wait! you say. It says that I have exactly 365 entries tagged with this tag. How can it keep an exact count of the number of entries I have tagged with this tag if it doesn't know exactly where all of them are? It counts them as they come in and go out. I know a lot of the stuff on LJ happens when an event triggers something else to happen, and the posting or deleting of a tag must be an event. Event: $TAG saved to entry; tick one more up on the tag counter. Event: $TAG removed from entry; tick one down on the tag counter. That's how it probably works behind the scenes, and that's the way it acts. If you need an analogy, think of your tag counter as a little person with a notebook standing outside the door of some event. They're counting the people who go in and out so they know how many people are inside, but they never know who the people are or where the people are inside the event, just how many there are.
Each tag is counted separately, and each tag counter and each tag view operates independently of each other. This can be annoying if you want changing one tag to re-tag the whole entry, but I could see how someone who has come to expect the current behavior could come to depend on it (say, editing a post that has fallen off the end of the apple tag view to add an orange tag, but without re-adding the post to the apple tag view at the expense of knocking a more recently tagged apple tag post off of the view).
What I would really like would be a re-tagging tool. It would be useful for anyone who has discovered that their entries have been tagged out of order, so that you have big chunks missing out of the middle of the tag view because the ones that should have been in the middle were tagged first and have fallen off first, or just people who have a lot of posts with a lot of tags and want to make sure that all of their entries were tagged and tagged in order. It wouldn't tag your entries for you; you'd have to do that, but once you had tagged them, it would go and tidy up their order, or make sure that your journal was taking full advantage of the new tagging limits.
The tool would go in from the chronological beginning of the journal and re-save all the tags on all the entries in chronological order. It would go in to edit the tags on that entry, cut the tags off from that entry, save the entry with no tags, paste the tags back on that entry, and save the entry once again fully tagged. It would have to be a polite bot, or I could see it being banned fast. It sounds like the sort of thing that LJ should offer as a paid service, so LJ can control the speed and make sure it isn't eating up resources. Like the entry security changer, it might only do a chunk at a time, and then e-mail the user when the whole process has been completed. It also sounds like it could be a risky thing; someone could lose all their tags if things weren't done right.
* I spent a fun and productive night experimenting with the exact practical limits of the tagging system at some point when the limit was 100. I was in IRC with the usual suspects, someone was curious, someone was bored, and I was the one who had over 100 entries in one tag. I wound up playing with my tags a lot that night. 100 entries was the smallest top-limit that we encountered when doing that, and it would occasionally show up to 120-ish entries, then reset back down to 100 entries, unless I was testing it wrong. Thus the tiny-binder-with-pages analogy, rather than a-clear-tube-full-of-marbles analogy.
When this change was announced in
lj_releases, the number one question I saw about this was: "So, I've got about 300 entries tagged 'bar', but I can't see them in /tag/bar; I can only see 100 -- what's wrong?" One of the things that was stressed in the lj_releases post was the concept from this point on, which was what a lot of people with this question weren't picking up on, or weren't fully understanding. If you haven't figured out how LJ's tag system works, this is completely confusing. The entries in the tag view are not searched out each and every time someone wants to look at a tag. They're modified if and only if someone saves a change to a tag. (
afuna demonstrated to me that merely opening an entry in tag edit mode and saving no-changes, or saving a change to a different tag on the same entry did not actually create a change in back entries of the specified tag that had fallen off the end of the tag-view, and now that I've thought about it for a while, I see why.) The tag view acts like it's the result of a list of entries possessing that specified tag. It displays sorted in chronological order by the displayed date on the entry (something that was posted in 2002 and was
But when you hit 100 entries, the little tiny binder starts getting uncomfortably crowded. (In actual practice, there's generally an 11th page*, but once that 11th page is full, there is No. More. Room.) At this point LJ flips back through the binder to the first page, rips the first page out and tosses it in the shredder and watches the shredded remains burn to ash, and sticks a new blank page in the back of the binder, and continues to faithfully record all the times entries are tagged in the new slots. There is nowhere that the locations of the old entries are stored as far as the tag view is concerned. (The analogy breaks down badly when you delete a tag from an entry in the middle; instead of crossing-through, it would have to white-out it over, and move all the entries up a line. Massive waste of correction tape & a whole lot of work.)
But wait! you say. It says that I have exactly 365 entries tagged with this tag. How can it keep an exact count of the number of entries I have tagged with this tag if it doesn't know exactly where all of them are? It counts them as they come in and go out. I know a lot of the stuff on LJ happens when an event triggers something else to happen, and the posting or deleting of a tag must be an event. Event: $TAG saved to entry; tick one more up on the tag counter. Event: $TAG removed from entry; tick one down on the tag counter. That's how it probably works behind the scenes, and that's the way it acts. If you need an analogy, think of your tag counter as a little person with a notebook standing outside the door of some event. They're counting the people who go in and out so they know how many people are inside, but they never know who the people are or where the people are inside the event, just how many there are.
Each tag is counted separately, and each tag counter and each tag view operates independently of each other. This can be annoying if you want changing one tag to re-tag the whole entry, but I could see how someone who has come to expect the current behavior could come to depend on it (say, editing a post that has fallen off the end of the apple tag view to add an orange tag, but without re-adding the post to the apple tag view at the expense of knocking a more recently tagged apple tag post off of the view).
What I would really like would be a re-tagging tool. It would be useful for anyone who has discovered that their entries have been tagged out of order, so that you have big chunks missing out of the middle of the tag view because the ones that should have been in the middle were tagged first and have fallen off first, or just people who have a lot of posts with a lot of tags and want to make sure that all of their entries were tagged and tagged in order. It wouldn't tag your entries for you; you'd have to do that, but once you had tagged them, it would go and tidy up their order, or make sure that your journal was taking full advantage of the new tagging limits.
The tool would go in from the chronological beginning of the journal and re-save all the tags on all the entries in chronological order. It would go in to edit the tags on that entry, cut the tags off from that entry, save the entry with no tags, paste the tags back on that entry, and save the entry once again fully tagged. It would have to be a polite bot, or I could see it being banned fast. It sounds like the sort of thing that LJ should offer as a paid service, so LJ can control the speed and make sure it isn't eating up resources. Like the entry security changer, it might only do a chunk at a time, and then e-mail the user when the whole process has been completed. It also sounds like it could be a risky thing; someone could lose all their tags if things weren't done right.
* I spent a fun and productive night experimenting with the exact practical limits of the tagging system at some point when the limit was 100. I was in IRC with the usual suspects, someone was curious, someone was bored, and I was the one who had over 100 entries in one tag. I wound up playing with my tags a lot that night. 100 entries was the smallest top-limit that we encountered when doing that, and it would occasionally show up to 120-ish entries, then reset back down to 100 entries, unless I was testing it wrong. Thus the tiny-binder-with-pages analogy, rather than a-clear-tube-full-of-marbles analogy.
no subject
no subject