https://www.prisma.io/docs/concepts/components/prisma-schema/postgresql-extensions

With the current implementation, this code:

datasource: {
  // rest
  extensions: `[pg_tgrm, zombodb]`,
  // rest
}

Evaluates to:

extensions = "[pg_tgrm, zombodb]"

Hi there, I am following this issue.

Please again look into this: https://codesandbox.io/s/exciting-leaf-bxqzvt?file=/src/schema.prisma Relation mixin is used by Request, Session, Token models, but it gets generated only for the Request.

If you want to, have a look into my full scheme: https://codesandbox.io/s/laughing-sun-u8sd54?file=/src/schema.prisma Basically a lot of models should contain the relation, but only CitationResponse and CitationRequest contains it.

Thank you in advance!

from 1.7.0 to 1.7.1 a change was introduced so that fields in a model are re-ordered, I think many users (including me) have their fields in a particular order - is there any way to control the order like was the normal behaviour before 1.7.1?

The new order of fields seems pretty random indeed. My preference would be that they are as they are written (i.e. how it used to be). The current order is not even alphabetical... schemas are a mess now

It looks like there's currently only support for creating a Prisma schema by creating specific folders to hold mixins, models, and enums. This seems like a great approach for the typical use-case where you want to programmatically create and maintain a project's schema.prisma file.

However, my use-case is a bit different. I'm trying to parse a GraphQL schema and build up a Prisma schema string on-demand. Essentially, I want to be able to independently create Prisma models, enums, and mixins and store them in variables, from which I'll later be able to create a complete (or partial) Prisma schema string by calling toString() on all of the objects and doing string concatentation.

I tried to get this to work by importing and using functions like createModel, createMixin, etc. and calling toString() on the resulting PrismaModels, but it doesn't look like this is possible because there's a check for an existing schema object here.

Has there been any thought given to being able to support such use-cases?

How to reproduce :

• use Windows 10
• clone the standard-usage example from the repo
• install latest schemix
• change import from ../../../dist to schemix
• npm start

result :

enum D:\Absolute\Path\on\Windows\Status {
  PENDING
  LIVE
  DELETED
  REMOVED
}

expected result :

enum Status {
  PENDING
  LIVE
  DELETED
  REMOVED
}

As per #35, this re-implements the ability for a purely programmatic approach to schema generation, models and enums can be created independent of a parent schema while retaining full prior functionality.

An example has been added in examples/programmatic-usage, in which an API which can generate basic models is created.

The core logic for this endpoint is as follows.

handler(context) {
  const { body } = context.request;
  const model = new PrismaModel(body.modelName);
  model.string("id", { id: true, default: { uuid: true } });

  for (const { type, name } of body.fields) {
    model[type](name);
  }

  return {
    status: 200,
    body: model.toString(),
  };
}

The README for said example is as follows.

This example creates an API at 0.0.0.0:8000 with a route in which you can send GET requests to a /model endpoint. It accepts the following zod schema.

validation.object({
  modelName: validation.string(),
  fields: validation.array(validation.object({
    type: validation.enum(["string", "int"]),
    name: validation.string(),
  })),
});

When a request is sent with the following body to 0.0.0.0:8000/model, it will respond with the subsequent string.

{
	"modelName": "ExampleModel",
	"fields": [
		{
			"type": "int",
			"name": "number"
		},
		{
			"type": "string",
			"name": "name"
		}
	]
}

model ExampleModel {
  id     String @id @default(uuid())
  number Int
  name   String
}

This should fix the order of the fields when using mixins, I basically wrapped all field setters in setImmediate. This currently passes all tests and outputs the expected schema. @ridafkih what do you think?

Also, I removed two snapshots that were obsolete.

Hi, when using .relation as this:

export default createMixin((UserRelationshipMixin) => {
  UserRelationshipMixin
    .relation("user", UserModel, {
      references: ["id"],
      fields: ["userId"],
    })
    .int("userId", { unique: true })
});

the resulting model is missing those fields. Please look into example: https://codesandbox.io/s/exciting-leaf-bxqzvt?file=/src/models/Session.model.ts As you can see, Token model has manually added those fields and everything is fine. Session model on the other hand is using mixin, and it lack those fields.

Thanks in advance :)

I noticed that there were some linting issues:

33 problems (33 errors, 0 warnings)
26 errors and 0 warnings potentially fixable with the `--fix` option.

So I have enabled checking and fixing those in the package.json.

I have ignored the example dir as I was seeing

The file does not match your project config: example/enums/Status.enum.ts.
The file must be included in at least one of the projects provided

I would suggest adding a pre-commit hook and / or a GHA CI workflow to check linting on PRs.

🤦🏼

Welcome to Node.js v16.16.0.
Type ".help" for more information.
> const a = ["banana", "apple", "pear"]
undefined
> const b = { fields: ["banana", "apple", "pear"] }
undefined
> typeof a
'object'
> typeof b
'object'
> Array.isArray(a)
true
> Array.isArray(b)
false

Since this has now bitten me, I have added support for jest unit tests and added 3 tests to make sure this doesn't happen again.

yarn jest
yarn run v1.22.17
warning ../../../package.json: No license field
$ /Users/lee/Code/nous/schemix/node_modules/.bin/jest
 PASS  lib/util/options.test.ts
  buildCompositeUnique
    with fields array
      ✓ should return correct composite unique value (1 ms)
    with options object
      without map
        ✓ should return correct composite unique value
      with map
        ✓ should return correct composite unique value

Test Suites: 1 passed, 1 total
Tests:       3 passed, 3 total
Snapshots:   0 total
Time:        0.373 s, estimated 1 s
Ran all test suites.
✨  Done in 1.03s.

I would suggest adding a GHA CI workflow to run this for PRs.

I would also suggest updating the package.json to reflect the new ability to run jest unit tests:

diff --git a/package.json b/package.json
index 9bb4364..959b963 100644
--- a/package.json
+++ b/package.json
@@ -11,7 +11,9 @@
     "lib": "lib"
   },
   "scripts": {
-    "test": "yarn build && cd example && yarn && yarn start",
+    "test": "yarn test:unit && yarn test:integration",
+    "test:unit": "yarn jest",
+    "test:integration": "yarn build && cd example && yarn && yarn start",
     "build": "tsc --declaration && tsc-alias"
   },
   "keywords": [

Lastly, I updated the .eslintrc to only lint *.ts files (since there is now a commonJS babel.config.cjs file due to jest) and also fixed the type roots in tsconfig.json (i.e. adding jest to types and also fixing the typeRoots to point to top level node_modules - FYI I believe typeRoots actually overrides types)

This PR supports putting enums / mixins / models in nested folders. This is particularly helpful to separate the models by domain folders:

- models
    - auth
        - Account.model.ts
        - VerificationToken.model.ts
    - order
        - Order.model.ts
        - OrderItem.model.ts  

Schemix should support providing descriptions for models and fields.

I haven't familiarized myself with the schemix source code yet, but I can give it try.

This is proposed functionality for importing TS/JS enums into the schemix/prisma. We can do this manually now, but it would be nice if the library could support this way out of the box. IMHO it should be preferred way to import JS enums, because it has numerous advantages.

• using enum anywhere / using already typed enums
• using default value for column from enum

Maybe better safety could be implemented because of this, not really sure for now. What do you think?

At the moment, in order to limit the length of strings, I need to do:

const User = createModel((User) => {
  User
    .string("id", { id: true })
    .string("setupId", { raw: "@database.VarChar(36)" })
})

It would be nice to support something like

const User = createModel((User) => {
  User
    .string("id", { id: true })
    .string("setupId", { maxLength: 36 })
})

or

const User = createModel((User) => {
  User
    .string("id", { id: true })
    .varChar("setupId", { limit: 36 })
})

or

const User = createModel((User) => {
  User
    .string("id", { id: true })
    .varChar("setupId", 36)
})

In order to add the "@database.VarChar(36)" automatically.

At the moment, if I want to define FPP, I need to do:

const Probability = createModel((Probability) => {
  Probability
    .string("id", { id: true })
    .decimal("probability", { raw: "@database.Decimal(3, 2)" })
})

It would be nice to support

const Probability = createModel((Probability) => {
  Probability
    .string("id", { id: true })
    .decimal("probability", 3, 2)
})

or

const Probability = createModel((Probability) => {
  Probability
    .string("id", { id: true })
    .decimal("probability", { precision: [3, 2] })
})

In order to add the "@database.Decimal(3, 2)" automatically.

At the moment, if I want to store just a date, I need to do:

const Report = createModel((Report) => {
  model
    .string("id", { id: true })
    .dateTime("reportDate", { raw: "@database.Date" })
})

It would be nice to be able to have something like

const Report = createModel((Report) => {
  model
    .string("id", { id: true })
    .date("reportDate")
})

which would automatically add the "@database.Date".

This is more of a nice to have, and completely understandable that you might want to just support native PostgreSQL types.

This could equally be implemented with a custom function (presumably).

Given an enum

const PlanType = createEnum((PlanType) => {
  PlanType
    .addValue("FREE")
    .addValue("PREMIUM")
})

and a model

const Plan = createModel((Plan) => {
  Plan
    .string("name", { id: true })
    .enum("type", PlanType, { default: "FREE" })
})

I want to ensure that the value passed as the default argument for the enum (e.g. { default: "FREE" }) is a valid value of the enum (i.e. ["FREE", "PREMIUM"]).

At the moment I am able to pass anything (e.g. .enum("type", PlanType, { default: "SOMETHING" })).