Looks like I made some mistakes in my previous message.
I attempted to reinstall my server, and now my first ID is 77.
Here’s what happened:
Set up the server.
Imported Organizations (failed due to a missing object attribute).
Attempted to import Organizations again (failed because the users were missing).
Successfully imported sanitized Organizations.
Now, the first ID (after Zammad Foundation) is 77.
While the increment shouldn’t be gone in my opinion, I don’t think this is a bug.
It’s an ID. It’s a counter. It doesn’t matter for your organization if the ID is 2 or 3201010.
I agree that burning through IDs does not have performance issues on Zammad, not sure where a possible performance issue was mentioned and that what is happening does not sound like expected behaviour.
It’s an ID. It’s a counter. It doesn’t matter for your organization if the ID is 2 or 3201010.
I might have to disagree here, since “ID” and “counter” are related concepts but serve different purposes.
In Zammad IDs are used to establish relationships between tables, like in workflows, triggers, and other functions.
While a counter is a mechanism used to generate unique, sequential numeric values for a specific column in a database table.
IDs and counters are not the same thing although it often happens that counters are associated with primary keys or ID columns to automatically generate consecutive numeric values as new records are inserted into the table, but the counter value increments should increment each time a new record is added, ensuring that each record receives a unique and sequentially increasing identifier. Which also in this case is not happening since the ID is being increased even when no data is being inserted.
So, if it not a bug, then it might be worth to mention this unexpected behavior in the documentation.
I just noticed that if one uses the API to import e.g. roles and it fails, the ID is not burned, this only happens when one uses the Zammad import function
