Adam Saghy created FINERACT-2097:
------------------------------------
Summary: Introduce String type keys - Part 3
Key: FINERACT-2097
URL: https://issues.apache.org/jira/browse/FINERACT-2097
Project: Apache Fineract
Issue Type: Improvement
Reporter: Adam Saghy
Part 2 - 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:
AbstractPersistableCustom interface generic type id: T extends Serializable -
instead of Long
this change effects all entity codes but transparent for the users
part 2:
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
enum type response data EnumOptionData is also generic and has a special
StringEnumOptionData
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
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
