nanoid support custom alphabet

[oriole-pub]

Most of the time, we need to define a special business ID field for models, such as post_id or user_id. We often choose UUID or nanoid for generating these IDs. However, when using nanoid, we found that it cannot meet our requirements because it defaults to generating IDs with uppercase letters and numbers. Sometimes we prefer IDs in lowercase letters and numbers, which nanoid cannot handle. As a result, we are forced to set the ID field as non‑nullable and generate a compliant ID in the code layer when creating records.

This is not an ideal practice. Providing a custom alphabet feature for nanoid would help reduce this mental overhead. Moreover, I believe the optimal API design would be:

• Keep the usage as is:
  @default(nanoid(16))

• Add an optional parameter when creating the client:

export const db = new ZenStackClient(schema, {
    dialect: new SqliteDialect({
        database: new SQLite(':memory:'),
    }),
    nanoidCustomAlphabet: "1234567890abcdef"
});

[sanny-io]

The ID generating functions already support prefixing. For nanoid, it's configured as nanoid(16, 'post_%s')

I think it would be better to add a parameter to ZModel's nanoid function that allows you to specify the alphabet, which would be a new 3rd parameter. That seems more appropriate than adding a configuration to the client itself.

[oriole-pub]

The ID generating functions already support prefixing. For nanoid, it's configured as nanoid(16, 'post_%s')

I think it would be better to add a parameter to ZModel's nanoid function that allows you to specify the alphabet, which would be a new 3rd parameter. That seems more appropriate than adding a configuration to the client itself.

Why I don’t think adding parameters is a good approach: typically, the generation rules for business IDs are consistent across an entire system. If there are 100 tables requiring business IDs, I would need to set the alphabet rules for 100 ID fields in the model, which seems quite redundant.

Of course, a better approach would be to base it on configuration while also allowing parameters to override it. However, from an implementation cost perspective, I think supporting configuration would be the simplest.

[sanny-io]

I see what you mean. There is already a lot of redundancy however because both the length and prefix must be specified for each model regardless. The alphabet is usually quite longer though so I understand why it would feel especially worse.

[oriole-pub]

I see what you mean. There is already a lot of redundancy however because both the length and prefix must be specified for each model regardless. The alphabet is usually quite longer though so I understand why it would feel especially worse.

Yes, the length is usually set by default, but a prefix is not always needed—it depends on whether the user requires it. In most cases, something like nanoid(16) is concise enough. However, adding an alphabet parameter would feel redundant. The alphabet string is typically not short, which is already problematic enough. Still, I'd like to hear your thoughts: do you think setting the alphabet via configuration is less user‑friendly than using a parameter?

[sanny-io]

You've convinced me @oriole-pub. I've slept on it, and I am now woke on the struggles people with hundreds of tables would have with an alphabet parameter.

I 👍 a client configuration. What do you think about nesting it this way? More extensible for the future, such as specifying a default length as well. Also, if the instantiation of the custom alphabet is the caller's responsibility it makes the implementation simpler.

What is also interesting is that customAlphabet can accept a default length for the 2nd argument too. Still, nesting the configuration rather than having it top-level is more organized I think.

export const db = new ZenStackClient(schema, {
    dialect: new SqliteDialect({
        database: new SQLite(':memory:'),
    }),
    
    nanoid: {
        customAlphabet: customAlphabet("1234567890abcdef")
    }
});

If there is agreement from the maintainers this would be fitting of a client configuration, then I can work on this feature. Not sure on a timeline, but probably sometime this month.

I can also give you pointers if you'd need it sooner and would be interested in working on it yourself.

[oriole-pub]

You've convinced me @oriole-pub. I've slept on it, and I am now woke on the struggles people with hundreds of tables would have with an alphabet parameter.

I 👍 a client configuration. What do you think about nesting it this way? More extensible for the future, such as specifying a default length as well. Also, if the instantiation of the custom alphabet is the caller's responsibility it makes the implementation simpler.

What is also interesting is that customAlphabet can accept a default length for the 2nd argument too. Still, nesting the configuration rather than having it top-level is more organized I think.

export const db = new ZenStackClient(schema, {
dialect: new SqliteDialect({
database: new SQLite(':memory:'),
}),

nanoid: {
    customAlphabet: customAlphabet("1234567890abcdef")
}

});
If there is agreement from the maintainers this would be fitting of a client configuration, then I can work on this feature. Not sure on a timeline, but probably sometime this month.

I can also give you pointers if you'd need it sooner and would be interested in working on it yourself.

Hey, I've been studying the source code of ZenStack v3, but after some further thought, if we really want to optimize this feature, it might not be limited to just allowing client-side configuration of nanoid generation rules. If we could support custom user-defined methods for generating IDs, the extensibility would likely be much better. The API might end up looking something like this:

// config
export const db = new ZenStackClient(schema, {
    dialect: new SqliteDialect({
        database: new SQLite(':memory:'),
    }),
    
    nanoid: {
        customAlphabet: customAlphabet("1234567890abcdef")
    },

    createId:(length:number)=>{
       // Code for custom generation of id
       return id;
    }
});

// model
id  @defualt(createId(1))

These API names are just preliminary ideas. We should find more appropriate ones. Such an implementation would certainly be more complex than simply making nanoid configurable, but it would offer better extensibility for ID generation.

I'd like to hear your opinion.

[sanny-io]

I like that idea too. Rather than a number for a parameter with the length I suggest an object containing the length which could also contain the name of the model for which the ID is being generated for.

Objects for parameters is a common pattern seen in zenstack and prisma. Leaves more room for future extensibility.

[sanny-io]

Let me know if you would like to see any additions to my PR in #2377 @oriole-pub

[oriole-pub]

Let me know if you would like to see any additions to my PR in #2377 @oriole-pub

I'm glad to see the PR on this issue so quickly. I think the current implementation is sufficient — it's a custom method, and users should be responsible for ensuring its correctness, so we don't need to impose too many restrictions.
I'd really like to contribute code to this issue, but unfortunately I've been too busy lately. Still, I'm happy that this is about to be resolved. Thank you.