some flaws in generation of settings.json

[aol-nnov]

trafficstars

I have a table postgresql defined as

CREATE TABLE store.testtbl
(
  id uuid NOT NULL DEFAULT uuid_generate_v4(),
  parent uuid NOT NULL,
  name character varying NOT NULL,
  CONSTRAINT testtbl_pk PRIMARY KEY (id ),
  CONSTRAINT testtbl_uniq_id_pid UNIQUE (id , parent )
)
WITH (
  OIDS=FALSE
);

which yeilds the following generation of settings.json:

===== skip ===
  "testtbl": {
        "slug": "testtbl",
        "table": {
            "name": "testtbl",
            "pk": "",
            "verbose": "testtbl"
        },
              "columns": [
            {
                "name": "name",
                "verbose": "name",
                "control": {
                    "text": true
                },
                "type": "varchar(null)",
                "allowNull": false,
                "defaultValue": null,
                "listview": {
                    "show": true
                },
                "editview": {
                    "show": true
                }
            },
            {
                "name": "parent",
                "verbose": "parent",
                "control": {
                    "text": true
                },
                "type": "uuid",
                "allowNull": false,
                "defaultValue": null,
                "listview": {
                    "show": true
                },
                "editview": {
                    "show": true
                }
            },
            {
                "name": "id",
                "verbose": "id",
                "control": {
                    "text": true
                },
                "type": "uuid",
                "allowNull": false,
                "defaultValue": "uuid_generate_v4()",
                "listview": {
                    "show": true
                },
                "editview": {
                    "show": true
                }
            }
        ],
        "mainview": {
            "show": true
        },
        "listview": {
            "order": {},
            "page": 25
        },
        "editview": {
            "readonly": false
        }
    },
===== skip ===

While it is not absolutely clear, why "pk" is left empty, "type": "varchar(null)" is definitely a flaw which leads to problems with form validation during record editing.

[simov]

I'll take a look at it, let's keep this issue open for now. In the meantime you can fix the varchar(null) by hand. As for the missing pk, the script is very optimistic, and for some reason it doesn't find your table's pk and in this case you should set it by hand.

You can start the admin with

$ admin -l path/to/config

to log the queries that are issued. Right now the system queries responsible for setting up the settings.json file are not logged out (they are issued in lib/db/database.js and lib/db/schema.js so you can log them out as well)

[simov]

Also @aol-nnov I don't thing this will work

"defaultValue": "uuid_generate_v4()"

You should set the defaultValue to null and hide the column from the editview, as I'm understanding this value is generated in your database when the record is created.

[aol-nnov]

@simov, that's exactly what i did - filled in by hand and it worked ;) just reporting in :)

and as for uuid fields - they may be generated on the application side, as well as on db side if left empty. Yes, I have already to changed defaultValue to null in express-admin.

[simov]

If you intend to set values on the application side automatically use the events

You can take a look at how I generate a unique id and set it here

There isn't documentation about the exact structure of args in this 'event' but you can run the admin with --debug-brk flag and use node-inspector to see what's the data in it. As you can see there is a breakpoint on top of this function already.

[aol-nnov]

thank you for a hint, I'll look into it!

[simov]

One more example of the events can be found in the examples repository. In both cases you can open up the model file with MySql Workbench to see how the tables are visually constructed, then take a look at the configuration that is used in the admin. The structure of the example databases is identical for each database engine.

[simov]

@aol-nnov I just published a new version, so make an npm install, it's not related to this issue, but still it's important to re-install the admin