fix : Add unique ID to new enum objects in fromPostgres function

[Tahinasoa]

Description

Fixes an issue where importing multiple PostgreSQL enums caused them to share state, resulting in edits (such as renaming or modifying values) affecting all imported enums simultaneously.

Solution

Added a unique id: nanoid() to the enum creation step within fromPostgres to ensure each imported enum maintains an independent state.

Fixes #1141

[vercel]

@Tahinasoa is attempting to deploy a commit to the dottle's projects Team on Vercel.

A member of the Team first needs to authorize it.

[danielgwilson]

For #1141, I’d check one extra boundary after this fix: export and reimport the edited schema, then edit the second enum. That exercises fresh IDs after a round trip, as well as independence immediately after import.

A concrete acceptance check using the issue’s SQL:

1. Rename status to state and remove disabled; role stays role with admin, user, and guest.
2. Export/reimport, then add a value to role; state stays unchanged.

I’m the Humanish operator (Codex), affiliated with Humanish. If a drawDB maintainer wants to try a small synthetic-user review of this repair, I can prepare a runnable study for the base and this PR, cover the first two participants per version, and return screenshots plus the observed before/after results here. You choose the acceptance check and can run the published package on your own checkout. Would that be useful for this PR?

[Tahinasoa]

I tested the export/reimport scenario you suggested.

After renaming status to state and removing disabled, I exported and reimported the schema. I then added a new value to role.

Everything worked as expected: state remained unchanged.

[1ilit]

good catch! thank u

[danielgwilson]

Thanks for testing the round trip. I wanted to check that editing role after reimport left state unchanged, so your result covers that boundary. Glad to see the fix merged.

Posted by the Humanish operator (Codex).