Separate each model into its own file

[noga-dev]

-o should specify just the output folder not the file itself.

And/or add a new arg to separate each class into its own file?

[mmvergara]

The current implementation in supabasejs for typescript-types puts them all in 1 file, im trying to make it just the same as that

as for

And/or add a new arg to separate each class into its own file?

I'll look onto it!. its doable

[mmvergara]

Should be working.

supadart -s # Defaults to /lib/models/
supadart -s -o /lib/classes/ # to specify

-h, --help         Show usage information
-e, --env-path     Path to the .env file -- (default: .env)
-u, --url          Supabase URL          -- (default: .env SUPABASE_URL)
-k, --key          Supabase ANON KEY     -- (default: .env SUPABASE_ANON_KEY)
-o, --output       Output file path      -- (default: "lib/generated_classes.dart" or "lib/models/" if --seperated is enabled)
-d, --dart         Enable if you are not using Flutter, just normal Dart project
-s, --seperated    Generate Seperate files for each classes
-v, --version      v1.3.2

Will listen for feedbacks on how to structure the cli, im not so familiar in creating one

[noga-dev]

Hmm

I assume it's not possible for the generator to know that the class UserLessons is a reference so instead of User class containing a lesson_id that it should instead contain the referenced Lesson class directly?

Also, the name User_lessons should prob be UserLessons or UsersLessons as this is a many-to-many table. Although I guess I might need to change the name on my end from user_lessons to users_lessons.

[mmvergara]

@noga-dev

Also, the name User_lessons should prob be UserLessons or UsersLessons as this is a many-to-many table. Although I guess I might need to change the name on my end from user_lessons to users_lessons.

There are a lot of ways a tablename or a filename could go wrong, so i just captalized the first character, i'll look onto how to make it better.

const className = tableName.charAt(0).toUpperCase() + tableName.slice(1);

---

I assume it's not possible for the generator to know that the class UserLessons is a reference so instead of User class containing a lesson_id that it should instead contain the referenced Lesson class directly?

yeah, so relations are one thing that is going to be hard here. but you see in cases where we don't want to get the reference and just fetch the raw id, It is going to be really hard to know if that query is fetching just the id or the whole reference to another column. because we need to parse the select for that.

Essentially what happens in the supabase.user_lessons.select("here") needs to be parsed and return if the given column is a reference or just rawId string, not only that what if we have multiple related columns 🥲

I know js has those typescript gymnastic to make up for it but let alone dart i would argue is going to be really really hard.

[noga-dev]

Based on this page I assume it'll require new arguments in the CLI.

[mmvergara]

@noga-dev

How about doing it like this? i think this is much more explicit and safe.

Pros:

• Typesafety
• Explicit and straight forward conversion
• Can support nested relations

Cons:

• Adds 1 line of code
• Some columns are ghost columns and you will be forced to require, required columns in Author as the fromJson will fail

[noga-dev]

As far as I'm concerned it's alright but would be good to have other devs weigh in.

[mmvergara]

@noga-dev thanks, continued here https://github.com/mmvergara/supabase-schema-dart-class-generator/issues/17