Forum: Bug Report and Feature Requests

Why do you reuse story ID numbers? If a story has been removed for some reason, the number should not be reused - that causes confusion.

There are probably a few people maintaining a local archive based on that id.

Another reason would be that an unnamed popular SOL scraping software save the origin url without the title slug as ids in Calibre. So when the user ask to update a story it will probably erase the old story.

I'll make a bug report to them.

Independently from that, having an immutable non reusable identification id, guid, sku, isbn to differentiate stories would be nice.

But I'm pretty sure the authors would manage to make a mess of it anyway by removing, rewriting republishing, reworking chapter limits, changing pen name and story titles...

The other option to help organize an offline story collection is plagiarism detection software. With the advantage that it works cross sites.

Another reason would be that an unnamed popular SOL scraping software save the origin url without the title slug as ids in Calibre. So when the user ask to update a story it will probably erase the old story.

I'd approve of changes to make it more difficult, not easier, to operate a scraping site.

However, a valid reason for avoiding reusing ids is that, currently links in forum posts to a story that is later removed can end up pointing at a completely different story!

(Technically, it would not seem difficult to have a monotonically-increasing seed (initially set to max(id)+1, say) that was used and incremented whenever a new id was needed. But I'm probably oversimplifying...)

(Technically, it would not seem difficult to have a monotonically-increasing seed (initially set to max(id)+1, say) that was used and incremented whenever a new id was needed. But I'm probably oversimplifying...)

auto-increment is one the very basic features that almost every database supports. This means that if you have an id-field set to auto-increment the next new id is automatically set when you insert a new record. The insert command can return that new id which then can be used as the relational id for related records.

Technically, it would not seem difficult to have a monotonically-increasing seed (initially set to max(id)+1, say) that was used and incremented whenever a new id was needed. But I'm probably oversimplifying...

The problem is that id has to be stored in a database. And no matter what data type you use, that fixes a finite pool of story ids

auto-increment is one the very basic features that almost every database supports.

And that creates a finite pool of possible IDs before the first record is inserted. Depending on the data type used, that pool could be very large, but it is still ultimately finite. Which means it could be exhausted.

And that creates a finite pool of possible IDs before the first record is inserted. Depending on the data type used, that pool could be very large, but it is still ultimately finite. Which means it could be exhausted.

A simple signed integer for a MySql/MariaDB database goes from -2147483647 to 2147483647. Make it an unsigned int and it goes up from 0 to 4294967295. You really think SOL will ever reach over 4 BILLION stories?
Even a medium unsigned int goes up to 16,777,215 and takes a byte less in storage. Not that storage size should be a problem nowadays. If there's any danger of exhausting to the max you have chosen the wrong numeric data type. An unsigned smallint goes up to 65535 which is very likely to be reached without reusing old numbers so that's not the numeric data type I would use.

You really think SOL will ever reach over 4 BILLION stories?

And back when the decision was made in early computer systems to store dates with a two digit year, no one thought that would ever be a problem. They didn't think those systems would be around long enough for it to become a problem. They were wrong.

I'm not saying I think SOL will reach 4 billion stories. However, building the system on the assumption that it will never happen, that it couldn't happen, is foolish.

However, building the system on the assumption that it will never happen, that it couldn't happen, is foolish.

That's not foolish, it should be well researched. For the two-digit date there was a VERY good reason back then and that had NOTHING to do with the assumption that it would never be a problem. Back then storage space and memory were very limited. The two-digit date simply required only half the storage and memory space. You can't compare the technological state back then to today and the programming decisions based on those states. I suspect the reason for the reuse of id's on SOL was a decision made way back at the start of SOL and at that time it was the best solution.

For an id it's pretty easy to predict the max that will never be reached, either logically or calculated. The simple use of a specific numeric integer guarantees you will never reach the limit. Nowadays there's never a reason to not use auto-increment for id's. The increment functionality in databases is generally much more reliable than anything you can program yourself.
The one exception is when a specific code or string is used as an id. For example a social security number.

It's generally a bad idea to use data as the primary key, even if it's 'guaranteed' to be unique. While it's rare, it's entirely possible to change your SSN in limited circumstances.

Oh, I agree that a unique id (primary key) should always remain the same for a record and should never be reused for different data. Many strange things can happen with related records if you do that :)
The SSN was just an example from the top of my head, I doubt very much that it is actually used as a primary key. Way back when, before a DBA was a separate job, some programmers preferred a 'human readable, recognizable, and meaningful' unique id. I'm betting today the first column a DBA adds to a new table is an auto-increment primary key field without consideration if it's ever going to be used (other than some queries require the presence of a primary key index).
What most users/readers don't understand is that nowadays a unique record identifier is rarely used for display, if used at all. That makes the displayed usage of the story id's on SOL rather unique (no pun intended).