Sample data create and import
Data creation and import is split into two tasks:
- create sample data (issue #29)
- import this data (issue #220)
The import is done via import file. Decision: simple for user.
Keeping the focus: the focus is creating sample data for the database, not import/export.
The above points were decided to be done this way in a phonecall with Timo.
This page aims to act as whiteboard for displaying current state and solving this task. The task itself is tracked in the two issue stated above.
Creating sample data
Goal: creating sample data for the database.
The sample data should have
- many donors
- many recipients
- many donations
List of sample data generators: http://www.webresourcesdepot.com/test-sample-data-generators/ . The majority of the software listed below was extracted from this page.
| Program | creates | area | Output | App-Type | License | |
|---|---|---|---|---|---|---|
| generatedata.com | Addresses / Cities / Countries | Netherlands, Canada, UK, US | XML, Excel, HTML, CSV, SQL | Webapp (JS,PHP,MySQL) | GPL v2 | |
| DBMonster | SQL | Command-Line (Java) | Apache License | |||
| CSV Data generator | CSV? | (Ruby) | ||||
| Datagenerator | library / GUI | GPL | ||||
| http://www.briandunning.com/sample-data/ | Website with real address data (US) but with fake names. This could be useful with testing map services as well since there are real geographic locations. |
Coding
Some coding has been done already: See csharp\ICT\PetraTools\GenerateSampleData for transforming sample data into family records etc.
Also see partner import module, which processes csv and yaml files. csharp\ICT\Petra\Client\lib\MPartner\gui\PartnerImport.ManualCode.cs
Importing sample data
The import is done via import file. Decision: simple for user.
Keeping the focus: the focus is creating sample data for the database, not import/export. Import/export is a simple tool - which we put effort into, to keep it nice and simple and easy to understand. But in this case, a tool for sample data only.
Make the import file as simple as possible for the user, e.g. consciously limit the scope of the import files capability (one address per person), but rather not powerful import-file.
Concider data liberation?
Not necessarily - only if useful to keep it simple and make it work quickly.
Intended location of data in OpenPetra
| Data | Table |
|---|---|
| Person | p_family |
| Address | - |
| Donations | - |
p_family will be used for all data, and p_person ignored (This is in line with the attempts to replace p_person by p_family).