We started a new farmOS Demo Records (farm_demo) module on the development call today. The goal is to be able to easily populate a farmOS instance with data (asset and log records) that mimic a real operation.
We may continue working on this together in the upcoming weekly dev calls. Anyone who is interested is welcome to join the process!
We can use this forum topic to track progress, and invite ideas from folks who are unable to join the calls.
CSVs that can be imported via the farm_import_csv module?
YML files that can be imported via the Default Content module?
What should trigger the data creation?
Automatically when the module is installed?
Manually by clicking a button in the UI?
Via Drush CLI commands?
… other?
How do we handle “shifting dates” so that the demo data appears “current”? (if the demo data has a timestamp in 2026, but someone installs it in 2036, we should shift the data to the present)
Do we need to be able to clean up (delete) demo data?
What happens if other records reference it?
Or do we just put a big warning somewhere? “Don’t use this on a real database!”
Can this tie into the setup wizard somehow?
The idea: the demo module may install certain modules to generate the data, and someone might want to start fresh with the same modules installed.
Conventions!
This module will naturally be following some conventions, so maybe it’s an opportunity to document them too.
This is the list I made on today’s call (certainly incomplete!)…
- farm_demo_land
- land assets (fields)
- farm_demo_plant
- plant assets
- seeding logs
- observation logs
- input logs
- harvest logs
- quick planting form
- farm_demo_animal
- animal assets
- medical logs
- observation logs
- birth logs
- harvest logs
- birth quick form
- movement quick form
...
Note: when I wrote that we were thinking about including multiple sub-modules (eg: farm_demo_land, farm_demo_plant, farm_demo_land) which each generate certain sets of data when they are installed.
But, now I’m leaning more towards this approach:
We could provide a simple settings form with options for generating data (and installing modules for it automatically).
We could also provide Drush commands, to do the same thing.
The Drush commands would allow for some useful automated testing / CI options.
In the past, we’ve talked a lot about leveraging the Default Content module for this, but now I’m starting to think more about the CSV option…
Some advantages to the CSV approach:
CSV is more approachable than YML. This will make it easier for folks to contribute to this project. You can open a CSV as a spreadsheet.
CSVs can be imported with the farm_import_csv module, which we already have. No new dependencies. And it means they can be tested easily, so someone who wants to contribute can make sure it works before suggesting new data.
The module could potentially provide custom CSV import templates and logic, so we have some flexibility with the CSV schema to make it very simple (or very complex!) CSV importers | farmOS
Other considerations:
Date-shifting might be easier in the CSV import process than in the Default Content import process… (needs more investigation). CSV import uses Migrate API which has the ability to preprocess the date fields to modify them on import.
Default Content creates content when a module is installed. It might be possible to trigger it programmatically instead… (needs more investigation). CSV import/migration can be done programmatically (we already do it in automated tests).
I’m assuming that one of the first things we’ll want to provide is a set of Land assets. Ideally these would include geometry.
What geometries should we use? There are privacy/PII considerations here, potentially.
Does someone want to volunteer their own geometries (and attest that they indeed have the ability to offer them publicly, knowing that they will forever be visible in a public Git history)?
Do we auto-generate geometries randomly? This side-steps the privacy issue, at the expense of a cohesive demo. It would be weird to see some geometries appear in the ocean, for instance.
Agreement that CSVs seem to be a good approach (for the reasons listed above).
Might be easiest to start simple and just create everything all at once (land, plants, animals, etc), rather than creating separate “sets” of data per-use-case - that can be split up in a v2, perhaps.
@mstenta is working on the basic architecture of the module (UI, Drush command, CSV importer integration, date shifting process plugin).
In the meantime we can start collecting some sample date. This can be done async by anyone who wants to help, just by creating and testing some CSVs with the existing CSV importer.
