[FINERACT-2097] Introduce String type keys - Part 3

• Type: Improvement
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Assignee: Unassigned
• Reporter: Adam Saghy
• Created: 13/Jun/24 11:53
• Updated: 13/Jun/24 11:57

Description

Part 3 - introduce string type keys

Why do we need support for String type primary keys?

Because

• generating a String type key is much faster than calculate the incremental next decimal value
• Stateless, it can be generated on the fly
• already known before the entity is saved
• globally unique: different entities and distributed systems, hosts/tenants could not produce exactly the same value
• sense of security since the malicious users can't guess the ID
• we advise to use nanoId, because it is tiny, secure, URL-friendly, cryptographically strong, has no mandatory dependencies, 60% faster than UUID and we can control the behaviour of alphabets to be used
• disadvantages:
  • not naturally sortable according to creation time - for that we introduced created_on_utc with nanoseconds
  • less user readable - suggest to have a user friendly name instead the primary key

What has changed?
part 1 (FINERACT-2091):

• AbstractPersistableCustom interface generic type id: T extends Serializable - instead of Long
  this change effects all entity codes but transparent for the users

part 2 (FINERACT-2095): 

• enum type response data EnumOptionData is also generic and has a special StringEnumOptionData

part 3 (FINERACT-2097):

• general APIs like command, datatables, journal entries and notes are now working with Serializable keys (not only Long)
• general services of command, datatables, journal entries and notes were extended to handle Serializable keys
• model extensions, new columns to store string type ids:
  • m_portfolio_command_source.resource_identifier varchar(100)
  • acc_product_mapping.product_identifier char(21)
  • m_note.entity_identifier varchar(40)
• dependency of com.aventrix.jnanoid:jnanoid:2.0.0