fix: enhance project initialization and menu transformation capabilities#631
fix: enhance project initialization and menu transformation capabilities#631NoOne7135 wants to merge 8 commits into
Conversation
…minForth/1647/do-not-create-a-prism-if-the-d
…djust imports in utils module
…DatabaseCleanState across data connectors
| ORDER BY id; | ||
| \`\`\` | ||
|
|
||
| ClickHouse does not enforce UNIQUE constraints like PostgreSQL, MySQL, or SQLite. AdminForth authentication expects \`email\` values in \`adminuser\` to be unique, so enforce this in your ingestion/application logic and remove duplicate email rows to avoid ambiguous logins.`; |
There was a problem hiding this comment.
@NoOne7135 actually I think we don't need it here, also I think we can safely remove all unique constraints form other DBs snippets. This should be specified in AdminForth resource config already - and it takes care about all of these on own soft layer. Hard unique constraints in DB are often more pain because if u have it here, but af layer will set unique to false, users will get direct db errors, instead of clear nice message (+other reasons) - so lets leave this decision for user, if he wants to get this pain - he can add it by himself.
Uniques - often create implicit index (but it is easier to create non unique index = same log2 access performance). Also UNIQUE is good of course for integrity, but adminforth will do it anyway by himself by additional checks.
There was a problem hiding this comment.
Also - please explain to user that all these snippets are just for example, we recommend him to use his favorite migration tool first. This is just example
| } | ||
|
|
||
| if (provider === 'mongodb') { | ||
| return 'Create an `adminuser` collection with `id`, `email`, `password_hash`, `role`, and `created_at` fields. Keep `email` unique in your own schema/index setup.'; |
There was a problem hiding this comment.
In mongo user has to do nothing ;)
It is not possible to create collection IMO. Mongo concept is just write to any collection any fields and mongo will create everything. So no additional steps should be needed. At least by mongo design
| }); | ||
| } | ||
|
|
||
| async isDatabaseEmpty(): Promise<boolean> { |
There was a problem hiding this comment.
I think prisma for mongo has no sense at all. Never. It works with mongo - yes. But not for migrations - this is for typesafe prisma client which we dont use anyway!
So nothing decide here - simply lets never include prisma for mongo. Thoughts?
No description provided.