Concept
Using the same analogy, our Instance can be called OpenG2P Registry
The individual tables – can be called Registers, so a Farmer Registry (Instance) will contain many registers
Farmer Register (Primary Register)
Land Holdings Register
Crop Register
Vehicle Register
Family Members Register
Farmer will have a single record in the Farmer Register (single entry)
The other registers will have multiple records (entries) against a single farmer
In some exceptional cases there might be 3rd level of hierarchy
Farmer has Land, Land has Crops
Can we have many Primary Registers in a single instance of Registry?
Practically - unlikely
But from a software perspective, we have no opinion.
Our registry can have multiple Primary Registers.
Tables - will be called “Registers” - so farmer_register, crop_register, worker_register, monthly_attendance_register, daily_attendance_register
Records in tables - will be called - “records” – so each farmer will have a record_id (of course we interpret it as farmer_record_id)
g2p_register_definition
register_id
register_mnemonic
register_description
master_register_id
program_application (boolean)
Methods
get_primary_registers (get registers with master_register_id as NULL)
get_child_registers (master_register_id)
get_program_application_registers
g2p_register_operations
operation_id
register_id
operation_mnemonic
operation_description
Json_form_schema_file_id - upload file
documents_required (boolean)
number_of_verifications_required
auto_approval (boolean)
g2p_register_documents
document_id
operation_id
document_mnemonic
document _description
g2p_register (Abstract Class) - This is the base class extended by all domain register models
internal_record_id
Primary Key - UUID
functional_record_id
MOSIP ID - Unique Index
link_record_id
Link ID to the parent register (internal record id) Non unique Index, if required Only applicable for slave, not master registers
created_at
last_updated_at
last_approved_by
search_text (TEXT, trigram indexing)
g2p_register_history (Abstract Class) - This is the base class extended by domain registory history models
Program application registers will not have history
history_record_id
Primary Key - UUID
internal_record_id
Non Unique Index
change_log_id
Non unique index
link_record_id
Non unique Index, only for slaves
created_by_id, created_by_name
approved_by_id, approved_by_name
g2p_register_change_log
change_log_id
register_id
internal_record_id
operation_id
change_payload (JSONB)
source_channel_id
changed_at
changed_by
approval_status
approved_at
approved_by
g2p_register_change_log_documents
document_id
change_log_id
g2p_register_verifications
verification_id
register_id
internal_record_id
operation_id
change_log_id
verified_by
verified_at
verification_observations
is_ok
g2p_register_service (Base Service Class) will have the following methods implemented
create_change_log
get_change_logs
delete_change_log
add_change_log_verification
get_change_log_verifications
approve_change_log
insert into implementation history table (dynamic sql)
upsert into implementation table (dynamic sql)
update change_log
validate_change_log
This will be abstract method, to be implemented by the domain model classes
Domain model classes can implement validations based on domain attributes
Any business logic based on domain attributes
farmer_register - extends - g2p_register
register_mnemonic = “farmer”
Based on register_mnemonic, the parent class methods will decipher the table_name
g2p_register_farmer & g2p_registry_history_farmer – for dynamic SQL operations
change_log and verifications - anyway are global tables.
There will be register_factory – that will return the appropriate register classes
g2p_registry_controller
/create_change_log
Get farmer_register - from factory
farmer_register.create_change_log
farmer_register
all dummy methods - calling - super.methods()
Only implements - validate_change_log – where validations on specific attributes be performed
Last updated
Was this helpful?