@spring-global/mseries-ef-build-schema
v1.3.6
Published
[//]: # (YOU CAN COPY AND READ THIS DOCUMENTATION USING: https://dillinger.io/)
Downloads
6
Keywords
Readme
Automatic Graphql/Spring-Ef Generation (By Spring)
This document show how to configure the normal use cases to automatic generate classes/interfaces and graphql for mSeries database entities.
How to Run
npm install
and then
npm run generate
The console should be as follows:
Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.
PS C:\TFS.WORK\SWProjects\CONA\Source Code\DevBranches\FaceliftReact\Mobile\MobileApps\ReactApp\build> npm run generate
> [email protected] generate C:\TFS.WORK\SWProjects\CONA\Source Code\DevBranches\FaceliftReact\Mobile\MobileApps\ReactApp\build
> ts-node --compiler typescript --project tsconfig.json ./src/index.ts
Initializing
Reading Schemas
Reading Config
Parsing Tables
parsing table cmSynchronizationStep
parsing table cmGenericProgressSteps
.
.
.
parsing table bzDivision
Assembling Entities
Emitting Entities
End with success
Config.json structure
Tables
"tables": [
{
"name": "bzAccountType",
"cacheType": "PreLoaded"
},
]
The Spring Ef has built-in 4 ways of accessing data:
- PreLoaded - All Table Data is cached on the startup and is always available
- AsyncPartial - Table Data is only cached when the record is required
- AsyncFull - All Table Data is cached when the entity is required for the first time
- NoCache - The Table Data is never cached
By default every table is considered a NoCache. If you want to change it for some entities you must contribute with the tables array and add the table name and cache type to it like in the exemple above.
Complex Entities
"complexEntities": [
{
"name": "Account",
"replaces": ["bzAccount", "slAccount"],
"tables": {
"main": "bzAccount"
},
"classification": {
"table": "bzAccountXClassification",
"idObjectType": "ACCT",
"values": [
{
"variableName": "idSalesOffice",
"cdClassificationType": "SOFF"
}
]
},
"attribute": {
"table": "bzAccountXAttribute",
"cdAttributeType": "ACCT",
"vlColumn": "vlAccountAttribute",
"values": [
{
"variableName": "vlAccountPhoneWork",
"cdAttribute": "AccountPhoneWork",
"cdParameterType": "PHONE"
},
{
"variableName": "vlAccountFax",
"cdAttribute": "AccountFax",
"cdParameterType": "PHONE"
},
{
"variableName": "vlAccountEmailWork",
"cdAttribute": "AccountEmailWork",
"cdParameterType": "EMAIL"
},
{
"variableName": "vlAccountHomePage",
"cdAttribute": "AccountHomePage",
"cdParameterType": "CHR"
}
]
}
}
]
A complex entity is a joint of entities like the bzAccount, slAccount, attributes and classifications. Instead of accessing each entity in a disjoint way the Spring-Ef allows us to combine thoses entities in a single complex entity.
Attributes:
- Name - The name of the entity
- Replaces: An array of tables that this entity is replacing
- Tables - The main table
- Classification - The classification structure
- Attribute - The attribute structure
Declaring Classifications
#note - We only support Single Level Classification Types for now
To add a new classification type you need to insert a new object to the Classification values array:
{
"variableName": "idSalesOffice",
"cdClassificationType": "SOFF"
}
- variableName - The name of the variable to use it on the javascript
- cdClassificationType - The classification code as is in the cmClassificationType table
Declaring Attributes
To add a new attribute you need to insert a new object to the Attributes values array:
{
"variableName": "vlAccountPhoneWork",
"cdAttribute": "AccountPhoneWork",
"cdParameterType": "PHONE"
},
- variableName - The name of the variable to use it on the javascript
- cdAttribute - The attribute code as is in the cmAttribute table
- cdParameterType - The parameter type as is in the cmAttribute table
Extended Schema
On mSeries we do not map every FK relation due to perfomance issue on ultralite. We rely on that to create the Navigation Properties on our final object schema.
So to be able to create the Navigation Properties there is a Extended Schema XML file (similar to the Ultralite DB Schema) that must be implemented with the FK relation that do not exist in run time
<?xml version="1.0" encoding="utf-8" standalone="no"?>
<ul:ulschema xmlns:ul="urn:ultralite">
<tables>
<table name="bzAccount" sync="changes">
<foreignkeys>
<foreignkey name="VFK_Account_AccountType" reftable="bzAccountType" check_on_commit="no" nullable="yes">
<mapping column="idAccountType" refcolumn="idAccountType" direction="asc"/>
</foreignkey>
<foreignkey name="VFK_Account_ObjectStatus" reftable="cmObjectStatus" check_on_commit="no" nullable="yes">
<mapping column="idStatus" refcolumn="idStatus" direction="asc"/>
<mapping column="idObjectType" refcolumn="idObjectType" direction="asc"/>
</foreignkey>
</foreignkeys>
</table>
</tables>
</ul:ulschema>
You can see that the schema to declare a FK on the Extended Schema is the same as in the normal schema. The builder will take care of merging the things in the right way and also as this is a separeted file it will not impact the final udb creation.