Hi, I’m not sure if this is a bug or a feature that needs to be built. I asked support about this once but didn’t really understand the response.
I’d like to request that Public ID’s generate in order of their “existence” within a database. That is, every new entity is the next Public ID after the previous one. If you had Task #69 and you create a new task, it’s Task #70.
I have noticed in our Fibery instance some odd logic behind Public ID creation that I haven’t been able to spend the time trying to figure out. But the bottom line is that swathes of #'s are bypassed. We are, for example, in the 500’s with our Project ID’s. That would make it appear that we’ve done 500 projects in Fibery, which we haven’t! Numerous of our other db’s would also “feel” more sensible if the ID’s grew with each added entity. An approach where each new ID comes after the next is typical for systems like Jira, and I think it adds value if you can see as a team your db’s growing through the logical expansion of the ID #'s.
Actually, public IDs are generated in incremental order, but IDs cannot be reused. So if you create 99 projects but then delete numbers 2 to 99, the next one will be given number 100, even though it appears to be only the second project that exists.
@Chr1sG , thanks for the response. That is what I would have assumed, but the reason I’m asking is I see some behavior that I’m pretty sure contradicts what you’re saying.
I am fairly certain we did not delete the entities in between the ones that are showing there. That is, we didn’t create #1, then delete the next 32. This is what I mentioned I asked support about a while back, but it was in intercom and since ou can’t search your intercom conversations I’m unable to find it right now. I am fairly certain we have this same “skipping” across many other db’s.
Also, while creating this image to post as an example, I just now noticed that it does not seem possible to sort a table by public ID, is that correct? That seems like something that would be a natural way to sort a db.
You can probably go through your audit log to see if there were items created between Dec 4th and Dec 10th to check whether it is behaving as expected.
Wrt sorting, since public ids are incremented for each newly created entity, sorting by creation date is the same as sorting by public Id (at least within a single database).
By the way, is there a particular reason why you would want to sort by public ID?
Ok thanks @Chr1sG for the response. I have looked at this issue closely enough to the point where I wanted to post this thread because it does not behave as you are suggesting. We have a few other db’s and they have similar patterns of skipping public ID’s. We did not create, then delete, those entities. If you want to I can post other db’s that have very similar patterns of skipping around 30 or so numbers when a new entity is created. At times this goes through #200 or so, so roughly 20 or so of the first entities will be numbered skipping at times 30 or so numbers to the point that the 30th or so entity in that DB is already #200.
One thing that occurred to me is that this may be something that was happening in the past, but recently fixed. Our very newest db, about 6 months old, does not have this pattern. But most I can see created before 2021 do have it. Since you have only been working on the Fibery team more recently than the db’s in question which skipped public ID’s in 2020, maybe you can ask internally about this? The problem is we have older dbs that are extremely relevant, like meetings, projects, etc. and the current # of the db is so high it is confusing - for example the projects I mentioned. When we bring in a new hire and start talking about Project #450 it just looks odd. So I’d really appreciate knowing what happened because I’d expect public ID’s to just go up by 1 as you create entities.
As for sorting, yes obviously I’m aware creation date would provide the same result as public ID. It is simply intuitive to be able to sort by any field in the db. If you guys think that’s redundant since you can sort by creation date, then that’s fine.
Thanks for posting all that - very useful. I shall indeed ask internally to see if there are reasons why the current intended behaviour is not being reflected in your workspace.
Absolutely not saying that it’s redundant, was just curious to better understand your flow and what use you make of the public ID value.
From what you say, it sounds like you and your team refer to projects internally via the public ID (which obviously makes much more sense than referring to them by the creation date ).
I went ahead and looked at this more closely, here is the very most recent db we created, if you notice it started last year, and there are no ID’s skipped here with entities created gradually over about a 9 month span:
I would appreciate if you could confirm if indeed there was some kind of bug with the ID’s in that late 2020 timeframe? Or otherwise explain the inconsistencies. We rely heavily on public ID’s.
).
