@ofceab generate not working

[medz]

          @medz  I just came to make these changes. I got the same error 

Originally posted by @ofceab in #313 (comment)

[medz]

@ofceab See https://github.com/medz/prisma-dart/tree/main/issues/ofceab_316

[medz]

[ofceab]

I tried to run your snippet and it works as excepted !
But When I put my prisma model and run the generate command then I got the same error bad state
I validated the model with npx prisma validate and every is fine. But somehow the generate command doesn't work for the model @medz

[medz]

@ofceab Can a repository be created and put a minimal example of failure? so that I can find and track this issue, otherwise I wouldn't know how to fix it

[medz]

Alternatively, invite me to your existing repository (if it's private)

Don’t worry, I will not leak your source code, it will only be used to find this bug. Of course, it would be best if you could create a minimal code repository that reproduces the bug.

[ofceab]

Great ! Give few minutes to try to debug the issue from orm source code, if not able I'll invited you kindly 😉

[ofceab]

Issue is got when a model name is written with underscore style i.e : client_job if we remove _ or change the name to something like clientjob or clientJob anything other combinations that doesn't contained _ then generation works fine !

Or if the orm can support such naming style it will be fine as well @medz

[yayahc]

I just migrated to ^4.0.0-alpha.0 and understand that now we should use PrismaUnion so I updated all my previous code and that was a lot of changes.
I don't know the benefit of PrismaUnion.
@medz

[ofceab]

There is some enforcement on the new generated models types.
When a field is marked as unique in the model definition, then for any update we have to provide that value even if we're not concerned about updating that field. Old version of the orm didn't require that.
Is it intented?

And if these field are update what happen under the hood after providing all these value ? I think these unnecessary values will be updated too.

I'm wondering then isn't going to affect a bit the performance?

In between really the code is fine, well refactored, and I'm happy that you bring nullable and decimal type

[medz]

@yayahc

I don't know the benefit of PrismaUnion.

Before 4.0, we chose the maximum input to try to support the maximum functionality.

However, the reference function has been added to the new version of Prisma, and the maximum input selection cannot satisfy the three major functions of "simple settings" / "data filtering conditions" and "field reference" at the same time.

Because in the early days Prisma only supported "simple settings" and "data filter conditions", the previous strategy was to select "data filter conditions" as the maximum input.

Another reason is that the maximum input condition still cannot meet the database null value setting.

So PrismaUnion returns and is removed when Dart supports Union type data.

[medz]

@ofceab Okay, I'll start fixing the bug where the model cannot contain _ strings.

In addition, you mentioned that there are a lot of unnecessary required inputs. Please give me a schema and a query code. I'll create a new issue for this and fix tracking the problem.

[medz]

@ofceab I released version 4.0.0-alpha.3, which fixes the bug that model names cannot contain underscores (_)

[ofceab]

Great news 🎉

I'll send you within few moments example for required fields

[yayahc]

Great 👍
Nice job @medz well refactoring and thanks for decimal type you save my time

[ofceab]

@medz Here is an example of model

`generator client {
provider = "dart run orm"
}

datasource db {
provider = "mysql"
url = env("DATABASE_URL")
}

model UserService {
id Int @id @default(autoincrement())
title String
description String
userId Int
user User @relation(fields: [userId], references: [id])
}

model User {
id Int @id @default(autoincrement())
name String
email String @unique
phone String @unique
servicePost UserService[]
}`

Now in the main I try to update the service link to another user for example

Here is the connect part you can see, It required to pass other unique value (like email and phone where I think ìd can satisfy alone this connection

[yayahc]

The same thing happens for findUnique()

[medz]

@ofceab fixed in 4.0.0-alpha.4 version

[yayahc]

Thanks for the quick fix, it's work well

[ofceab]

@medz I'm not sure, but I tried to find fluent API within this 4.0 version, I can't have that API.
Is this feature removed ?

[medz]

@ofceab Yes, I deleted the fluent API, which is my intention. I found several disadvantages of fluent API:

1. Excessive and deep selection of data, which will cause unnecessary query queries (even if no data is required to be returned)
2. Unclear and conflicting data conditions - where of the fluent API automatically contains the relationship conditions of Parent. The parameters of the fluent API are consistent with the model delegate, resulting in wrong condition settings, such as prisma.user.findFirst().posts() will automatically add posts where author_id = user.id, if we pass posts where author_id what author_id= 2?
3. It is boring to increase the volume of the code. With more and more models defined by schema, the relationship becomes more complicated. The fluent API is essentially the transfer of a select args, so there will be a lot of extension code. Again It will limit your extension client in your code.

[ofceab]

@medz I understand. Good insight.
So let's move to push 4.0 to a stable state

[medz]

@medz I understand. Good insight. So let's move to push 4.0 to a stable state

@ofceab https://prisma.pub/getting-started/ I spent a lot of time writing examples and docs, which should now be used as the basic documentation for version 4.0. All codes in the documentation are bound to the actual runnable code in the example!

In the coming days, I will write some more in-depth documentation.

I'm actually torn on whether I should let 4.0 enter the next beta stage. In my case, I started a massive rewrite of 4.0 a few months ago with the intention of promoting progress on Dart Union types so that Dart Union types can happily remove the PrismaUnion type in future releases.

Another, original plan was for me to implement a Prisma C ABI engine to bring Prisma to Flutter. But Prisma revealed in the community that they are working on a C ABI engine. I don't know if I should wait for them.

There is another problem, maybe you have discovered it, all the tools I maintain almost never write tests.

[ofceab]

@medz, if I understand, you want to allow the use of Prisma directly within flutter allowing apps to be able to directly interact with database ?

I did some searches and found this prisma/prisma-engines#3106 (comment), great jobs !
For me if it's possible to build that C ABI engine without waiting for them, It will be great, as until now we don't know more on they progress.
Is there something i can do to help to reach that vision you have ?

For failed test, yes I noticed it since alpha.0. We need to have them working as well before move to stable. I think 4.0 is ready for beta stage as you said.