When I press the edit button, the page resets and I just appear on the same post, I can usually resolve it by pressing the reload button then pressing edit, but I just thought someone might need to know for whatever reason.

This bug appeared today, and I use chromium (chrome, for Linux essentially) operating on Linux 10.04 (Which I hate).

Can you tell us what post(s) you're trying to edit and what tags you're removing/adding?

As long as all of us ~ motions to a mostly empty room, just us three and that guy who spitting in all the plastic cups ~ are on the topic of tags, is there a specific way artist tags are made?

Fuzzball said:
As long as all of us ~ motions to a mostly empty room, just us three and that guy who spitting in all the plastic cups ~ are on the topic of tags, is there a specific way artist tags are made?

artist:artistname

Fuzzball said:
As long as all of us ~ motions to a mostly empty room, just us three and that guy who spitting in all the plastic cups ~ are on the topic of tags, is there a specific way artist tags are made?

When applying a tag to an image, prefix the tag with "artist:" like "artist:narse". That will both create an artist tag and switch a tag that already exists to an artist tag.

Riversyde said:
artist:artistname

So like this? artist:deaffinity

Riversyde Char

Thanks bro's.

There's no such thing as an "artist tag".

A tag is a tag, but you can have a tag announce that it's of a certain type, such as a tag referring to an artist.

char:loltag artist:loltag loltag copy:loltag all refer to the same tag, just adding it with the prefix causes the tag's type to change.

Kind of stupid and unintuitive IMHO.

Kitsu~ said:
There's no such thing as an "artist tag".

A tag is a tag, but you can have a tag announce that it's of a certain type, such as a tag referring to an artist.

char:loltag artist:loltag loltag copy:loltag all refer to the same tag, just adding it with the prefix causes the tag's type to change.

Kind of stupid and unintuitive IMHO.

wow

Kitsu~ said:
There's no such thing as an "artist tag".

A tag is a tag, but you can have a tag announce that it's of a certain type, such as a tag referring to an artist.

char:loltag artist:loltag loltag copy:loltag all refer to the same tag, just adding it with the prefix causes the tag's type to change.

Kind of stupid and unintuitive IMHO.

wat

I've spent a lot of time analyzing e621's tagging system, as I'm coding something similar.

Another stupid thing is how destructive and inefficient implications and aliases are, it actually results in the creation and deletion of attached tags, instead of just affecting searching and presentation.

It would be much better to handle search queries more smartly, if someone searches for a tag that gets implied (friendship_is_magic, for example), it should search for all posts with any tags that imply it.

Storage efficient, scales much better, creating (approving, rather) aliases and implications is extremely fast. Can do cool things like user-independent implications too.

Kitsu~ said:
I've spent a lot of time analyzing e621's tagging system, as I'm coding something similar.

Another stupid thing is how destructive and inefficient implications and aliases are, it actually results in the creation and deletion of attached tags, instead of just affecting searching and presentation.

It would be much better to handle search queries more smartly, if someone searches for a tag that gets implied (friendship_is_magic, for example), it should search for all posts with any tags that imply it.

Storage efficient, scales much better, creating (approving, rather) aliases and implications is extremely fast. Can do cool things like user-independent implications too.

If all you're going to do is bitch about a tagging system, that you yourself are so called "Analyzing" then maybe you should think about leaving, before the door smacks you on the way out.

Princess_Celestia said:
If all you're going to do is bitch about a tagging system, that you yourself are so called "Analyzing" then maybe you should think about leaving, before the door smacks you on the way out.

Or, you know, make feature suggestions. We have a pretty good track record with those I think.

Princess_Celestia said:
If all you're going to do is bitch about a tagging system, that you yourself are so called "Analyzing" then maybe you should think about leaving, before the door smacks you on the way out.

How can I make suggestions when the administration gets all hostile the moment someone suggests that their tagging implementation might just not be the digital embodiment of every deity combined.

Char said:
Or, you know, make feature suggestions. We have a pretty good track record with those I think.

Because despite it's problems, it is still very good, it probably wouldn't be worth the effort to improve it. And I don't even know if what I'm doing can be done on PostgreSQL (e621's database, right?) efficiently.

But here's a suggestion that is much easier to do: Change the scoring system, make it thumb-based, and have the final score be a percentage based on how many of the thumbs were up, that way a post's score is more accurate for comparing between popular/controversial posts. Right now, a post's score is highly affected by how old it is, and how often it shows up in the comments section.

Kitsu~ said:
It would be much better to handle search queries more smartly, if someone searches for a tag that gets implied (friendship_is_magic, for example), it should search for all posts with any tags that imply it.

wait... I'm not sure I understand...

let's say blue_hair implies hair.

Explain what you mean using this implications. I can think of a lot of different ways this might be read and I"m not sure how much scene any of them make, so I must be missing something.

SnowWolf said:
wait... I'm not sure I understand...

let's say blue_hair implies hair.

Explain what you mean using this implications. I can think of a lot of different ways this might be read and I"m not sure how much scene any of them make, so I must be missing something.

It's a way of querying a database for posts, that takes implications into consideration at querytime, which is more efficient and scales better compared to e621's method of handling implications.

In your example, if you searched for hair the software will ask the database for all posts that have either the blue_hair tag and/or the hair tag.

What e621 would do is just search for hair, and it will expect the implication to have previously added the hair tag to all posts with blue_hair.

It's not exactly simple, so you're not an idiot if you don't understand.

Actually, Kitsu, I think that's the wrong way to look at things. Searching is what you expect to happen all the freaking time. Posts and tag edits only happen occasionally, by comparison. So, if I were to burden either side with the work for implications and aliases, it would be the tag editing side, not the searching side.

ikdind said:
Actually, Kitsu, I think that's the wrong way to look at things. Searching is what you expect to happen all the freaking time. Posts and tag edits only happen occasionally, by comparison. So, if I were to burden either side with the work for implications and aliases, it would be the tag editing side, not the searching side.

You're not wrong, optimising for reads is generally the way to go, just in this case, you don't lose much performance when searching (it requires determining which tags imply a specific tag, and more index lookups), but you gain a lot when applying an implication (more importantly, it scales well when applying, and is atomic, and easily reversible).

It's also a lot more fault-tolerant, in e621's system, if the database goes down while doing a large update (updating attached tags for any arbitrary number of posts) than things will be half-finished. It's not something that can be done atomically without some heavy locking (which will affect the performance of at least all relevant posts while it's taking place.

Having slightly slower searching is a very good price to pay for being more memory efficient, storage efficient, scalable, atomic and dynamic.

If I understand correctly, implications basically mean that tag A should never occur without tag B. So, since (to use the previous example) a picture should never be tagged with "blue_hair" without also being tagged with "hair" (you can't have blue hair if you have no hair at all, obviously), I don't see any point in having a search for hair look for instances of blue_hair since it makes perfect sense for a picture to be tagged with the hair tag in the first place.

Apart from the practical reasons for having implicated tags added as actual tags, not only would you first have to look up which implications exist for the current search, but you also could have blue_hair, black_hair, brown_hair, long_hair, short_hair, curly_hair, etc., all of which would imply hair. You could easily have a dozen implications or more, which would all have to be checked whenever someone searched for just "hair". Now I admit that SQL optimization is not really my cup of tea, but this doesn´t seem efficient to me as you´re effectively adding unnecessary database checks and search parameters to every single search query. And as ikdind mentioned, searches are likely to happen a hell of a lot more often than implication edits.

Sure, creating a new implication would be less stressfull with the system you propose, but I don't see how that possibly makes up for complicating every single search. I'm assuming e621 has adequate transaction and error handling to prevent massive fuck-ups if something goes wrong halfway through an implication update, and even if it doesn't I doubt it would be that much of a hassle to re-do the implication process.

Having slightly slower searching is a minor issue indeed, but causing more stress on the database server isn´t. And in that respect, having slightly faster searches would be more important than having slightly faster implication edits.

Wahai said:
If I understand correctly, implications basically mean that tag A should never occur without tag B. So, since (to use the previous example) a picture should never be tagged with "blue_hair" without also being tagged with "hair" (you can't have blue hair if you have no hair at all, obviously), I don't see any point in having a search for hair look for instances of blue_hair since it makes perfect sense for a picture to be tagged with the hair tag in the first place.

Apart from the practical reasons for having implicated tags added as actual tags, not only would you first have to look up which implications exist for the current search, but you also could have blue_hair, black_hair, brown_hair, long_hair, short_hair, curly_hair, etc., all of which would imply hair. You could easily have a dozen implications or more, which would all have to be checked whenever someone searched for just "hair". Now I admit that SQL optimization is not really my cup of tea, but this doesn´t seem efficient to me as you´re effectively adding unnecessary database checks and search parameters to every single search query. And as ikdind mentioned, searches are likely to happen a hell of a lot more often than implication edits.

Sure, creating a new implication would be less stressfull with the system you propose, but I don't see how that possibly makes up for complicating every single search. I'm assuming e621 has adequate transaction and error handling to prevent massive fuck-ups if something goes wrong halfway through an implication update, and even if it doesn't I doubt it would be that much of a hassle to re-do the implication process.

Having slightly slower searching is a minor issue indeed, but causing more stress on the database server isn´t. And in that respect, having slightly faster searches would be more important than having slightly faster implication edits.

For one thing, I'm not using a SQL-database, I'm using MongoDB. You'd only need 3 queries, one to fetch the tags that the user is searching, one to fetch all the tags that imply the ones you are searching, and the post search query itself. It's a good idea to do the first one, so you alert the user if they misspelled a tag they are searching for (instead of silently failing), so there's only one additional query, which may be as simple as "get all documents with these ids" if you store implication information on the tags themselves. 3 queries in total, 2 of which are highly cacheable.

Kitsu~ said:
It's also a lot more fault-tolerant, in e621's system, if the database goes down while doing a large update (updating attached tags for any arbitrary number of posts) than things will be half-finished. It's not something that can be done atomically without some heavy locking (which will affect the performance of at least all relevant posts while it's taking place.

Actually, I think that's a really good point. I'm used to thinking in terms of databases that can either "go down for maintenance" periodically, or are snapshotted every so often so the snapshots can be presented to end-users in a read-only fashion (where serious datamining occurs, so read performance still trumps all).

E621 is up and mutable 24/7 so your choices are either to block the tables for a large atomic write, or risk incomplete jobs by doing it in batches, or bite the bullet and take the hit on the searching side.