IdGen is generating 17bit Id instead of 16bit? What should we change in the method so that it generate 16 bit Id instead of 17 bit now and in the future it continuous to generate 16 bit Id? about idgen

[RobThree]

Again: if that is your actual code, then you're using the IdGenerator very, VERY wrong. You're creating a new instance of the IdGenerator on each and every call to GenerateId(), and not only that but also an instance of IdGeneratorOptions, IdStructure, DefaultTimeSource and a DateTime. That's 5(!) objects you're creating each call 😱

You should create an IdGenerator ONCE (per host/process/thread) and keep using that instance. As I pointed out: read the FAQ. And also see my provided example.

But even when I use your (incorrect) code I get ID's with 16-bit id-parts (though they're all zero since, again, you're using it wrong):

0000000001001011110000010101011001010001101000000000000000000000
|\___________________________________________/\/\______________/
|                       |                     |         |
|                       |                    Host       |
|                       +---> Date/time part            +---> Id-part
+---> MSB (Always zero)

Please show how you generate an ID and come to the conclusion that there's a "17 bit" id-part.

[RobThree]

I'm afraid you don't understand how bits and bytes work. Those numbers are BOTH 64 bit numbers. ALL ID's generated by IdGen are ALWAYS exactly 64 bits and parts of those bits are assigned different meanings (we have a date part (45 bits in your configuration), a host/generator part (2 bits in your configuration) and a sequence/id part (16 bits in your configuration).

[RobThree]

Again, I can't stress this enough: you are using IdGen wrong. Very, VERY wrong.

but as you can see here it is generating two different digit when we change the year

That's because when you go from ... 97, 98, 99, 100, ... you also get an "extra digit". Thats how numbers work 🤪

Their might be way we can generate the 16 digit number

No there isn't. Yes, IdGen CAN produce 16 digit numbers but then, AGAIN, you're trying to fit a square peg into a round hole. IdGen doesn't care about digits. Hell, it doesn't even care about bits, it's always a 64 bit number it generates. And if those 64 bits just so happen to fit in a 16 digit decimal representation then.... that's just... "luck" I guess.

The way you're using it is just flat out wrong on multiple levels. You might as well just generate a random number and cross your fingers and hope there won't be a collision (which there WILL be - exactly what IdGen is designed to avoid - if used correctly). If this is how you've been actually using it "for a long time" then you've been lucky that you've never had a collision (which also means you're not producing at least 2 ID's per millisecond, which is where you got lucky). Also you're keeping your Garbage Collector busy for no reason. As pointed out several times by now: an IdGenerator should be a singleton in a given context (be it a host/process/thread/...). You're creating a new instance for every generated Id which makes the use of IdGen utterly useless; everything it is designed to do is thrown overboard. You might as well just use a timestamp in decimal form at this point (if that fits in 16 digts... maybe use DateTime.Now.ToString("yyyyMMddHHmmssff") or whatever, which is, essentially, what you've been doing in a very roundabout way anway).

If you insist on 16 digit numbers (WHY? You still haven't explained why you have this (pretty weird) requirement in the first place) then please switch to another method of generating Id's. Or... I dunno... keep burying your head in the sand, ignore the actual problem and just... chop off some digits 🤷‍♂️ Or bitwise AND the generated Id with 0xFFFFFFFFFFFFF 😬

I can't help you. IdGen can't help you. You need to get back to the drawing board, make sure you understand the basics and figure out how you want to go on from there.

[RobThree]

Could you please post code as text next time? Now I have to painstakenly manually copy your code by typing it in instead of copy/pasting to reproduce.

But first things first: are you sure you're not seeing a bit of the generator ID set?

Could you provide a complete, minimal reproducible example?

Also: Am I understanding your code correctly that every time you call GenerateId() you create a new IdGenerator? In that case: don't. You need to create one instance, once, and use that. See our FAQ.

Looking for your prompt response!

Was this prompt enough?

[RobThree]

I've tested, in my example the host bits are always 00 and the id-part is always at most 16 bits.

Even if you're using the IdGenerator incorrectly as in your example, I don't see how it would generate 17 bits id-parts.

[dpatusb]

  public static long GenerateId()
  {
     return new IdGenerator(0, new IdGeneratorOptions(new IdStructure(45, 2, 16), new DefaultTimeSource(new DateTime(2020, 8, 4, 0, 0, 0, DateTimeKind.Utc)))).CreateId();
  }

---

Above is the general method I have created to generate the 16 bit Id, which is now generating 17 bit Id.
If I am changing year in the Date time to 2022 from 2020, it is generating 16 bit again.
Can you please let us know how we can prevent this?

[RobThree]

Wait... I just realized...

If I am changing year in the Date time to 2022 from 2020, it is generating 16 bit again.

So... according to you:

21323332180770816 this is 17 bits?
4789388835553280 this is 16 bits?

[dpatusb]

Now you get what is the actual problem

[dpatusb]

Wait... I just realized...

If I am changing year in the Date time to 2022 from 2020, it is generating 16 bit again.

So... according to you:

21323332180770816 this is 17 bits? 4789388835553280 this is 16 bits?

Is there a way I can generate 16 digit number/id ?

[RobThree]

Is there a way I can generate 16 digit number/id ?

Not with IdGen, but I also don't see how that would be a sane requirement in any realistic common scenario. Do you know why this requirement exists?

[dpatusb]

We are using IdGen from a long time and might be it was generating 16 digit number when we implemented this code, but as you can see here it is generating two different digit when we change the year. Their might be way we can generate the 16 digit number, which can solve our problem, as this generated id is a primary key for our reference table.

It would be great if you will help us to solve this issue.

Thanks