[
https://issues.apache.org/jira/browse/FINERACT-2097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Saghy updated FINERACT-2097:
---------------------------------
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
was:
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:
* 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
* 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 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
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
