You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Expanding short URLs that are aliases of another — of which at least one always exists when any URL is saved as more than one slug — currently increments its own stats & those of the canonical URL.
If a slug that is currently canonical for some URL, and it has aliases, but then the slug is redefined, the alias slugs are implicitly redefined as well. (Not that redefining slugs is a smart idea.)
Original rationale / current implementation
If a URL is shrunk to the slug “a” and then later manually assigned the slug “b,” the entry for slug “a” is rewritten to be an alias (internal redirect) for slug “b.”
The reason this was done is so that when Lessn More is asked for a short URL for the original URL later, it returns the one that was manually assigned (“b”).
However, I’m not wholly convinced this is a smart arrangement anymore — it would be stupid, but what if “b” was later re-assigned to a new URL? Then “a” would change, too (as an alias for “b”). You shouldn’t change short URLs anyway, but is that the right thing to do?
A Better Way?
Probably a better idea is to add a boolean (slash tinyint) field that would designate “b” as the canonical short URL. The query used to retrieve a slug for the original URL would prefer but not require slugs with the canonical flag. This would have the following effects:
No longer would it take more than one SQL query to follow a non-canonical URL
Aliases would no longer increment the stats for multiple slugs, as they currently do
The stats page would not have trouble showing aliases anymore.
Obviously a database migration would be required.
Another thought
The double-increment of stats however sounds like a bug that could be worked out without necessarily requiring a database migration.
Likewise the stats page could be improved to show aliases more accurately and/or show the long URL as normal.
The text was updated successfully, but these errors were encountered:
Problems with the Status Quo
Original rationale / current implementation
If a URL is shrunk to the slug “a” and then later manually assigned the slug “b,” the entry for slug “a” is rewritten to be an alias (internal redirect) for slug “b.”
The reason this was done is so that when Lessn More is asked for a short URL for the original URL later, it returns the one that was manually assigned (“b”).
However, I’m not wholly convinced this is a smart arrangement anymore — it would be stupid, but what if “b” was later re-assigned to a new URL? Then “a” would change, too (as an alias for “b”). You shouldn’t change short URLs anyway, but is that the right thing to do?
A Better Way?
Probably a better idea is to add a boolean (slash
tinyint
) field that would designate “b” as the canonical short URL. The query used to retrieve a slug for the original URL would prefer but not require slugs with the canonical flag. This would have the following effects:Obviously a database migration would be required.
Another thought
The double-increment of stats however sounds like a bug that could be worked out without necessarily requiring a database migration.
Likewise the stats page could be improved to show aliases more accurately and/or show the long URL as normal.
The text was updated successfully, but these errors were encountered: