You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat: add support for multiple database connections (#146)
* feat: new migrations folder structure for model-defined database connections
* fix: do not generate static adapters index
* fix: utils require path in migrations template
* feat: explicit naming for default databases
* fix: access internal sequelize model reference
* tests: remove and ignore instance folders
* fix: case-insensitive storageType check
* feat: updated integration tests toolchain to use yarn workspaces
* docs: added new flags to man page
* fix: use distro node-jq binary
* fix: yarn workspace not cleaning acl_rules
* fix: branch checkout should delete generated code
* feat: remove yarn and jq dependencies from CLI
* feat: add helper for standard logs
* fix: remove npm install from restartContainers()
* chore: handle branch checkout in workspace
* refactor: remove redundant function
* fix: increase test 21. Limit check timeout to 10s
* chore: remove deprecated sequelize config
* fix: remove unused paths from .gitignore
* docs: updates and fixes to the project README
* fix: change docs from yarn to npm run
* fix: -g should not crash if servers are not created
* fix: remove ReconstructDb from comment
* chore: use logTask for output messages
* feat: async check and wait for gql server start
* refactor: renamed T1 -> SERVER_CHECK_WAIT_TIME
* refactor: do one thing, do it well; better log messages
* fix: docker-compose creates empty node_modules
* refactor: extract waitForGql() from doTests()
* fix: out of place log
* refactor: remove redundant checkCode() function
* fix: do not attempt to list servers if the workspace has not been set
* fix: using -b should checkout, fetch, and reset <branch>
* chore: bump 0.2.0 -> 0.3.0
Copy file name to clipboardExpand all lines: README.md
+82-86
Original file line number
Diff line number
Diff line change
@@ -1,16 +1,15 @@
1
-
# Code-generator
1
+
<h1align=center>Code Generator</h1>
2
2
3
-
Command line utility to auto-generate the structure files that [this server](https://github.com/ScienceDb/graphql-server)
4
-
will use to perform CRUD operations for each model created.
3
+
Command line utility to generate the structure files that Zendro [graphql-server](https://github.com/Zendro-dev/graphql-server) will use to perform CRUD operations for each model created.
5
4
6
-
## Set up:
5
+
## Set up
7
6
Clone the repository and run:
8
7
```
9
8
$ npm install -g
10
9
```
11
10
If you only want to install it locally run `npm install` instead
12
11
13
-
## Usage:
12
+
## Usage
14
13
15
14
To run the unit-test case:
16
15
```
@@ -22,82 +21,103 @@ To run the integration-test case
22
21
$ npm run test-integration [-- OPTIONS]
23
22
```
24
23
Note:
25
-
Intergation-test case creates a docker-compose ambient with three servers:
24
+
Integration-test case creates a docker-compose environment with three servers:
26
25
27
-
gql_postgres
28
-
gql_science_db_graphql_server
29
-
gql_ncbi_sim_srv
30
-
31
-
By default, after the test run, all corresponding Docker images will be completely removed from the docker, this cleanup step can be skiped with __-k__ option.
26
+
```
27
+
gql_postgres
28
+
gql_science_db_graphql_server
29
+
gql_ncbi_sim_srv
30
+
```
32
31
33
-
Please run this utility with __-h__ option to see the full documentation in manpage style.
32
+
### Examples of use - Test integration
34
33
35
-
## Examples of use - Test integration:
36
34
To see full test-integration info:
37
-
```
35
+
```bash
38
36
$ npm run test-integration -- -h
39
37
```
40
-
To restart containers:
41
-
```
42
-
$ npm run test-integration -- -r
38
+
39
+
To execute a default test run:
40
+
```bash
41
+
$ npm run test-integration
43
42
```
44
-
To generate code and start containers:
43
+
44
+
To test a specific `graphql-server` branch:
45
+
```bash
46
+
$ npm run test-integration -- b <branch_name>
45
47
```
48
+
49
+
To generate code:
50
+
```bash
46
51
$ npm run test-integration -- -g
47
52
```
48
-
To do the tests only and keep the containers running at end:
49
-
```
50
-
$ npm run test-integration -- -t -k
51
-
```
53
+
52
54
To generate code and do the tests, removing all Docker images at end:
53
-
```
54
-
$ npm run test-integration -- -T
55
-
```
56
-
To do a full clean up (removes containers, images and code):
57
-
```
55
+
```bash
58
56
$ npm run test-integration -- -T
59
57
```
60
58
61
-
62
-
And to generate the structure files:
59
+
To generate code, do the tests, and keep the containers running at end:
If you want to complete the example with the [server](https://github.com/ScienceDb/graphql-server)
86
-
make ```/your_path_directory``` the same directory where the server repository is stored.
87
93
88
-
NOTE: For displaying the explanation about usage we can run the help flag:
89
-
```
94
+
For help using this command:
95
+
96
+
```bash
90
97
$ code-generator -h
98
+
99
+
# Code generator for the GraphQL server
100
+
#
101
+
# Options:
102
+
#
103
+
# -f, --jsonFiles <filesFolder> Folder containing one json file for each model
104
+
# -o, --outputDirectory <directory> Directory where generated code will be written
105
+
# -h, --help output usage information
91
106
```
92
-
```
93
-
Code generator for GraphQL server
94
107
95
-
Options:
108
+
This command will create four sub-folders within the `output-directory` folder, containing the generated files for each model:
109
+
96
110
97
-
-f, --jsonFiles <filesFolder> Folder containing one json file for each model
98
-
-o, --outputDirectory <directory> Directory where generated code will be written
99
-
-h, --help output usage information
100
111
```
112
+
models/ -> sequelize model
113
+
schemas/ -> graphQL schema
114
+
resolvers/ -> basic CRUD resolvers
115
+
migrations/ -> create and delete table migration file
116
+
```
117
+
118
+
To use the code generator with the [graphql-server](https://github.com/Zendro-dev/graphql-server),
119
+
use its path in the `output-directory`.
120
+
101
121
102
122
## JSON files Spec
103
123
@@ -107,15 +127,15 @@ For each model we need to specify the following fields in the json file:
107
127
108
128
Name | Type | Description
109
129
------- | ------- | --------------
110
-
*model* | String | Name of the model (it is recommended uppercase for the initial character).
111
-
*storageType* | String | Type of storage where the model is stored. So far can be one of __sql__ or __Webservice__ or__zendro\_server__
112
-
*url* | String | This field is only mandatory for __zendro\_server__ stored models. Indicates the url where the zendro server storing the model is runnning.
113
-
*attributes* | Object | The key of each entry is the name of the attribute and theres two options for the value . Either can be a string indicating the type of the attribute or an object where the user can indicates the type of the attribute(in the _type_ field) but also can indicates an attribute's description (in the _description_ field). See the [table](#types-spec) below for allowed types. Example of option one: ```{ "attribute1" : "String", "attribute2: "Int" }``` Example of option two: ``` { "attribute1" : {"type" :"String", "description": "Some description"}, "attribute2: "Int ```
130
+
*model*| String | Name of the model (it is recommended to Capitalize the name).
131
+
*storageType* | String | Type of storage where the model is stored. Currently supported types are __sql__, __Webservice__, and__zendro\_server__
132
+
*url*| String | This field is only mandatory for __zendro\_server__ stored models. Indicates the URL of the Zendro server storing the model.
133
+
*attributes*| Object | The key of each entry is the name of the attribute. There are two options for the value: a string indicating the type of the attribute, or an object with two properties: _type_ (the type of the attribute) and _description_ (attribute description). See [types-spec](#types-spec) table below for allowed types. Example of option one: ```{ "attribute1" : "String", "attribute2: "Int" }``` Example of option two: ``` { "attribute1" : {"type" :"String", "description": "Some description"}, "attribute2: "Int ```
114
134
*associations* | Object | The key of each entry is the name of the association and the value should be an object describing the associations. See [Associations Spec](associations-spec) section below for the specifications of the associations.
115
135
116
136
EXAMPLES OF VALID JSON FILES
117
137
118
-
```
138
+
```jsonc
119
139
//Dog.json
120
140
{
121
141
"model":"Dog",
@@ -139,7 +159,7 @@ EXAMPLES OF VALID JSON FILES
139
159
140
160
```
141
161
142
-
```
162
+
```jsonc
143
163
//Publisher.json
144
164
{
145
165
"model":"Publisher",
@@ -175,7 +195,7 @@ Date |
175
195
Time |
176
196
DateTime |
177
197
178
-
For more info about `Date`, `Time`, and `DateTime` types, please see this [info](https://github.com/excitement-engineer/graphql-iso-date/blob/HEAD/rfc3339.txt).
198
+
For more info about `Date`, `Time`, and `DateTime` types, please see the [graphql-iso-date/rfc3339.txt](https://github.com/excitement-engineer/graphql-iso-date/blob/HEAD/rfc3339.txt).
179
199
180
200
Example:
181
201
* Date: A date string, such as `2007-12-03`.
@@ -211,7 +231,7 @@ name | Type | Description
211
231
## NOTE:
212
232
Be aware that in the case of this type of association the user is required to describe the cross table used in the field _keysIn_ as a model in its own. For example, if we have a model `User` and a model `Role` and they are associated in a _manytomany_ way, then we also need to describe the `role_to_user` model:
213
233
214
-
```
234
+
```jsonc
215
235
//User model
216
236
{
217
237
"model":"User",
@@ -235,7 +255,7 @@ Be aware that in the case of this type of association the user is required to de
235
255
}
236
256
```
237
257
238
-
```
258
+
```jsonc
239
259
//Role model
240
260
{
241
261
"model":"Role",
@@ -258,7 +278,7 @@ Be aware that in the case of this type of association the user is required to de
258
278
}
259
279
```
260
280
261
-
```
281
+
```jsonc
262
282
//role_to_user model
263
283
{
264
284
"model":"role_to_user",
@@ -275,7 +295,7 @@ Be aware that in the case of this type of association the user is required to de
275
295
It's important to notice that when a model involves a foreign key for the association, this key should be explicitly written into the attributes field of the given local model.
276
296
277
297
Example:
278
-
```
298
+
```jsonc
279
299
{
280
300
"model":"book",
281
301
"storageType":"sql",
@@ -301,7 +321,7 @@ THE SAME DATA MODELS DESCRIPTION(.json files) WILL BE USEFUL FOR GENERATING BOTH
301
321
302
322
Fields *`label`* and *`sublabel`* in the specification are only needed by the GUI generator, but backend generator will only read required information, therefore extra fields such as *`label`* and *`sublabel`* will be ignored by the backend generator.
303
323
Example:
304
-
```
324
+
```jsonc
305
325
//book.json
306
326
{
307
327
"model" : "Book",
@@ -329,27 +349,3 @@ Example:
329
349
## Testing
330
350
331
351
For relevant files see `package.json` (section scripts), directories `.test` and `docker`. Test framework is `mocha` and `chai`.
332
-
333
-
### Unit tests
334
-
335
-
Run all existing unit tests with
336
-
```
337
-
npm run test-unit
338
-
```
339
-
340
-
### Integration tests
341
-
342
-
#### Requirements
343
-
344
-
You need to be on a \*nix operating system, and have bash and Docker installed and running.
345
-
346
-
Integration tests are carried out using Docker to setup a GraphQL web server and generate code for example data models. The last step of the setup is to create databases and migrate schemas. After that the server is started using `localhost:3000`, which can than be accessed using HTTP. Solely via such HTTP connections the generated API (GraphQL web server) is tested, just as a user might be doing with e.g. `curl`.
347
-
348
-
All related Docker files are stored in `./docker`; especially `docker-compose-test.yml`.
349
-
350
-
The test pipeline is defined and executed in `./test/integration-test.bash` for reasons of simplicity. The actual integration tests are written using `mocha` and can be found in `./test/mocha_integration_test.js`, which is invoked by the above bash script.
0 commit comments