As of now, there is no provision of initial dummy data for contributors to work with.
Fixtures are to be added for pre-population of all models.
@yadavankit Thanks for opening this issue. This is going to be super useful for all the contributors. :)
If you want to work on this issue, please do some research about the packages available out there and let me know whichever is reasonable and once we converge in choosing a package, you can start writing a code.
Let me know if you have doubts.
I remember that at some point @RishabhJain2018 was looking at some of the packages available for the same but then he got busy with some other issues.
@RishabhJain2018 can you please share the list of packages that you filtered out? It will save a plenty amount of time.
@deshraj I had researched about these packages for adding the initial fake data.
Please review the document. What are your views about it ?
Moreover, Can I work on this?
@RishabhJain2018 I guess u already have #649 ? Moreover, am not occupied with any issue as of right now.
Thanks @RishabhJain2018 for sharing the doc. I will look at it soon.
@yadavankit, don't worry, he is just pointing us to some of the links that he searched earlier. It makes sense to use this doc as reference since it will save a lot of time of ours. :)
@RishabhJain2018 thanks for the doc 馃槃 @deshraj I have already gone through the shared doc and doing my research on packages. Will update soon :)
@deshraj @TroJan does the sum of durations of all challenge phases of a particular challenge equal to the duration of the Challenge?
Also, what about seeding of Leaderboard (having a JSONField schema) ?
@deshraj @TroJan does the sum of durations of all challenge phases of a particular challenge equal to the duration of the Challenge?
Yeah, you should keep it that way though we have the flexibility of keeping to different duration.
Also, what about seeding of Leaderboard (having a JSONField schema) ?
We can talk about it once you are done with the rest part and open a pull request.
@yadavankit any progress with this? This is going to be super important really soon so please do it quickly. Let me know if you need some help with this.
@deshraj Yeah, will be submitting the PR for review soon :)
@deshraj @TroJan in Submission model, why are we using submitted_at when Submission model is itself TimeStampedModel ? (I am receiving naive-datetime warnings on seeding the Submission model for submitted_at field that has auto_now_add set to True)
@yadavankit We are using the TimeStampedModel to just keep track that when a particular entry was created or modified. We have explicitly added the submitted_at field to make sure all the variable names are consistent for the submissions and we should not confuse with created_at for this. Moreover, it's not bad to have extra fields since you might want to use it in the future. :)
@deshraj got it, thanks :)
Fixed in #756