Support Hi/Lo for database key generation....

[natiki]

Would improve performance as it eliminates database round trips:

• https://stackoverflow.com/questions/282099/whats-the-hi-lo-algorithm
• https://vladmihalcea.com/the-hilo-algorithm/
• http://www.talkingdotnet.com/use-hilo-to-generate-keys-with-entity-framework-core/

[hikalkan]

Is it something different that https://github.com/volosoft/abp/blob/master/framework/src/Volo.Abp.Guids/Volo/Abp/Guids/SequentialGuidGenerator.cs ?

[natiki]

It is different to the Hi/Lo implementation but I believe it is superior as it

1. Can all be done client side and requires no interaction with the database server
2. As it is a GUID (or part of) there will be no sequence clashes

It does have some downsides however:

1. Unless clients are time synced there can be performance issues because the sequence being generated will overlap (in terms of the time portion) so inserts will not be guaranteed to be at the end.
2. You need to "know" which SequentialGuidType to use based on the underlying field type and DBMS
3. Storage of the same GUID value will not match unless the same SequentialGuidType is used for say a primary key and a foreign key. An of course the GUID when stored in Oracle will never match SQL Server in this method.

I don't see that much can be done about 1) and if performance is an issue then a time server being included on each work station would be something that DevOps would take care of.

As for 2) this ultimately will mean that the POCO will not be DBMS agnostic unless.... the POCO would be declared something like:

public class MyTableModel
{
  [AbpSequenceGuid]
   public Guid Id {get; set;}
}

and when the migrations are generated the apropriate data type is chosen for the destination database? So for SQL Server uniqueidentifier, Oracle uuid etc.?

To mitigate 3) I would think we need to create some extension methods so we can change between SequentialGuidType given an existing generated value.

Conclusion:

Using this Guid approach definitely gets my support as long as 2) and 3) can be solved with my proposed solutions or something similair.

[hikalkan]

Thanks @natiki for details. Will spend time on that.