-
-
Notifications
You must be signed in to change notification settings - Fork 695
Support running multiple instances on v3 #3273
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I was thinking more about this over the weekend. Is the main purpose of the If so would it not be better to hash the collection before creating the tables and then add the hash to the end of the table name so it would end up looking something like This could provide a much more efficient startup and would resolve the issue with multiple running Nuxt instances. |
@GerryWilko I think I'm running into this as well ("Nuxt Test Utils with multiple parallel workers"), wondering if you've found any workarounds? |
This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 30 days. |
Bumping this issue, because it's had no activity. :/ |
Uh oh!
There was an error while loading. Please reload this page.
Is your feature request related to a problem? Please describe
Currently we are unable to reliably use Nuxt Content v3 with Nuxt Test Utils with multiple parallel workers as Nuxt Content adds content to a static set of SQL tables.
The following reproduction demonstrates the issue:
https://github.com/GerryWilko/content-sql-repro
Describe the solution you'd like
I would like to be able to safely run Nuxt Content v3 with multiple Nuxt instances connecting to the same DB.
During module initialization all existing content tables are dropped:
content/src/module.ts
Lines 253 to 254 in 96a9c4a
If we are already dropping all the content tables on module initialization we could just use a set of scoped tables within the same DB with a unique ID generated on module init. This would allow for each Nuxt instance to only interact with its own tables.
This solution may be problematic for users that are not using the built in SQLite server as they will end up with many duplicate copies of their content files. However at present if they are running multiple instances then each one is perhaps unnecessarily clearing the content dbs and they may be hitting this race condition of instances clashing with each other on start.
Describe alternatives you've considered
Alternatively we instead stop calling
dropContentTables
on module initialization and instead perform a clean-up operation of orphaned content files in each content table after content has been injected into and overwritten what is already present.Additional context
The text was updated successfully, but these errors were encountered: