Table name vs class name

[bookshiyi]

Currently, the class names is generated from table names, such as :	table(database)	class(dart)
books	Books
musics	Musics
movies	Movies

Could we change the generated class names to singular form?	table(database)	class(dart)
books	Book
musics	Music
movies	Movie

For example, maybe we could arrange the comments of table are singular form of the table name。 When supadart generates class, use the comments of the table as the class name.

[mmvergara]

I see singular form would actually make sense, or We could do something like, if char s is in the end remove s? what do you think?

[bookshiyi]

Some words can't get the singular form by remove the s at the end. Family → families Bus → buses Person → people Child → children

Or could we create a plural-singular table as a configuration file, store it in the repository? and query this file every time when we generate class code.

Or query the singular form by AI?

[mmvergara]

The config file is indeed a viable solution. However, I prefer not to introduce config files and would rather have the tool rely on Supabase.

So maybe we can stick to your original idea of using table comments, they are available in the api and then we can do something like [supadart:custom_comment]

const tableComment = "This is a sample comment with [supadart:custom_classname] inside it.";
const match = tableComment.match(/\[supadart:(.*?)\]/);

if (match) {
    const result = match[1];
    console.log(result); // custom_classname
}

what do you think?

[bookshiyi]

It is sound great that the table with a comment like[supadart:custom_comment].

About configuration file,I just had an idea inspired by you. Cloud we place the configuration file to the local .env file, the mapping data is manually written by the user before running. like this:

.env file:

SUPABASE_URL=https://xxx
SUPABASE_ANON_KEY=xxx

+ TABLE_TO_CLASS = {
+  "books":"book",
+  "products": "product",
+  "categories": "category"
+}

[mmvergara]

i see this is indeed a better way. I'll implement it tomorrow asap.

[mmvergara]

@bookshiyi so trying to implement this now, few problems arise.

> + TABLE_TO_CLASS = {
> +  "books":"book",
> +  "products": "product",
> +  "categories": "category"
> +}

The process would be like

1. Get the TABLE_TO_CLASS from env
2. Convert that to a map<string,string>

Then the challenging part is modifying the class names. While there are methods available for string replacement, I have concerns about their safety and implementation. Additionally, this approach would require code modification in the CLI component, whereas I'd prefer to limit code changes to the API generation if possible.

I was thinking of going back to the table comment [classname:custom_model_name].

But id like to hear your thoughts on this. maybe its just a skill issue in my side.

[bookshiyi]

I don't quite understand what the safety problem you are talking about is.

The modification of cli, maybe only need to add a json field to the original url request.

Do I understand correctly?

[mmvergara]

yeah i did not realize that, now that the generators are in dart, we can forget about that.

I really like this approach now, but as far as i remember .env files doesnt support multiline and just treats values as single line?.

[bookshiyi]

I have made some attempts, and the .env file does not support multi-line definitions.

Next, I will try to use format like yaml or toml.

[mmvergara]

we can probably use the existing pubspec.yaml?

[bookshiyi]

we can probably use the existing pubspec.yaml?

yeah！it is very interesting.

[bookshiyi]

How do you think about that delete all parameters in cli then define these into xxx.yaml file like this:

supadart:
  # Required, your supabase server url
  supabase_url: https://xxx.supabase.co

  # Required, your supabase anon key
  supabase_anon_key: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

  # Optional, where to place the generated classes files
  output: lib/models/

  # Optional, if you want to generate seperate files for each classes
  seperated: true

  # Optional, if you are not using Flutter, just normal Dart project
  flutter: true

  # Optional, used to map table names to class names(case-insensitive)
  mappings:
    books: book
    categories: category
    children: child
    people: person

The cli only has these options:

Usage: dart script.dart [options]
-h, --help           Show usage information
-c, --config       Path to config file of yaml            -- (default: "pubspec.yaml")
-v, --version        v1.3.8

The developer can set the parameters in any .yaml file and default is pubspec.yaml

[mmvergara]

First of all thanks for opening up a PR, I appreciate the great ideas, but I have mixed feelings about this approach. It seems to add more steps compared to simply running supadart to generate the necessary files.

My intention behind requiring SUPABASE_URL and SUPABASE_ANON_KEY in the environment variables is based on the typical setup for a Supabase Flutter project. By default (I think?), these environment variables are already in place, making it straightforward to just run supadart.

This new approach, however, would require an additional step to fill out the pubspec.yaml, which goes against the goal of maintaining simplicity.

I get that its safe to expose both env values but there still some developers out there who prefer not to commit them.

Would it be possible to:

1. Check if SUPABASE_URL and SUPABASE_ANON_KEY are present in the .env file; if not, use the values from pubspec.yaml.
2. Retain the parameters as they are, and if provided, let them override the values in pubspec.yaml else use the one provided in the pubspec.yaml.

[bookshiyi]

As you said, even if url and annokey can be safely made public, there are still many developers who don't want to let more people know these. btw, if developers want to disclose their url and annokey, they can use the {customize}.yaml file and ignore it in .gitignore file.

The currently supported input methods and priorities are as follows: {customize}.yaml > pubspec.yaml

Of course, I also understand that referring to .env files can facilitate different code calls in a project. It's just a pity that it's difficult for env to store mappings configuration(table to class). If env, yaml and options coexist, it will probably be a little too complicated like this: cli options > {customize}.env > .env > {customize}.yaml > pubspec.yaml

I think the cli options can be provided, but maybe we should avoid two types of configuration files.

Thanks for your patient reply, there may be other better solutions, but we haven't found them yet.

btw, some packages similar to this: https://pub.dev/packages/flugger https://pub.dev/packages/swagger_parser https://pub.dev/packages/swagger_dart_code_generator

[mmvergara]

@bookshiyi I see, given that maybe we could do something like

• keep the options as they are
• add a supadart --init command to generate a supadart.yaml file
• Priority where to get the config.
  • In the given options
  • In the supadart.yaml file
  • If both doesn't exist, fall back to defaults

so we only support, supadart.yaml, this goes for individual configs