[
https://issues.apache.org/jira/browse/FINERACT-2097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Saghy updated FINERACT-2097:
---------------------------------
Description:
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
was:
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
> 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
> Priority: Major
>
> 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)
