-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Get the db-reset working with Docker #76
Comments
Can you explain what you mean by seeds and The only way I could see that this could be done is that the mongo Dockerfile would have to know all about the domain, obviously we would need a mongo dockerfile (not that that's an issue https://github.com/binarymist/NodeGoat/blob/DockerNonRootUser-mongo-experiment/app/data/Dockerfile). The two ways I can see:
Thoughts and other ideas please @ckarande @Pamplemousse ? |
@Pamplemousse it would be helpful if you could elaborate more about database.json and seeds. |
The other option is... Don't do anything. How many people does this affect? It's also increasing the complexity and LoC, which is not something that should be taken lightly. |
Good point. As of now, nodegoat doesn't demonstrate any issues that are dependent on mongodb. So we could provide an option to use in memory db (using https://github.com/typicode/json-server or similar) as part of the config . For docker deployment, users can choose this option to avoid all the hassle about mongo container without affecting the what NodeGoat has to offer. |
This is a bit of a tangent though isn't it? in-memory would just replace what we have now with the same functionality. User looses data on container start. Doesn't actually solve the problem highlighted by @rrequero and @Pamplemousse , just makes things less complex from where they are currently, right? Don't get me wrong, I like the idea, but doesn't address this issue. NodeGoat isn't supposed to be a production app, as far as I'm aware, so maybe it is the way to go |
I need to give some more thought as well, but I was imagining to insert the seed data (which is part of the the db-rest currently) into in-memory version of mongo db (such as this https://www.npmjs.com/package/mongo-mock). So each time the container starts, the data is gets added to the in-memory db first. Most of the in-memory db for mongo are just npm modules, mainly designed to aid testing. It would run as part of the application code. However, I am also not completely convinced with this approach, as it would pollute app code with concerns related to creating seed data in in-memory db. Plus, I am not sure if all required features are supported in any mongo in-memory db module to run it seamlessly. |
The whole issue @Pamplemousse had was that the seed data should be inserted at container creation time, not run-time, so each time the container is started, the same data exists that existed when it was stopped. So, the container (Dockerfile) needs to handle this. If we don't do anything, then the behavior you are suggesting still occurs, because when the container starts currently, the data-store is re-seeded. |
Ah..thank you for clarifying it. If that is the case, I agree we shouldn't do anything about this issue. As you mentioned, nodegoat is not a production level app. So I wouldn't worry about the minor overhead of inserting data at container run-time. It is not a huge amount of data, so it is not worth engineering a solution for knowing the complexities involved. Based on these inputs I am closing this issue. @Pamplemousse if you do not agree or have any other suggestions, please feel free to reply with a comment. |
As you said, this is maybe a bit of an over-engineering problem considering the usage of the nodegoat project. Maybe future selves will change our minds, so I will clarify what I meant ; for the record. SeedingSeeds are data stored in a readable format in files (e.g .yml) that are read by a tool to populate the database. However, as @binarymist in his first answer:
Even if database seeding is a weel-spread practice, it does not really fit this project: increasing complexity, containers with too many responsabilities. This is kind of what the Database.jsonWhich lead me to the second solution: The idea is to version an initial state of the db (containing basic data: make an export right after the current From there, use I think this would not break the current ways of doing things. |
Following discussions from #70, it seems that the
db-reset
process needs some update to work well (and elegantly) with all the installation options.What do you think about:
database.json
containing a initial version of the database?The text was updated successfully, but these errors were encountered: