prop_seed table constraints unnecessary?
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Bauble |
Triaged
|
Wishlist
|
Unassigned | ||
1.1 |
Triaged
|
Wishlist
|
Unassigned |
Bug Description
Have noticed that entering propagation data, cannot save information unless I enter seed numbers and sowing date. That is because they are 'not null' in table properties.
A couple of scenarios where 'not null' on these fields is a disadvantage:
-If i am planting Eucalyptus or Juncus seeds by the gram, or by the spoonful, I may not wish to enter a value for 'number of seeds' (unless I choose to guessitmate, or have a 'seeds-per-gram' conversion value).
-If I have some Macaranga germinate naturally in a stockpile of potting mix, from an unknown number of seeds dispersed naturally, and I do not know the germination date, I currently have to make up values for both entries in order to save propagation data that I do know/want, such as when and how many germinated.
Are there reasons that Bauble or the db needs values for both these fields?
footnote - for the example of sowing seeds by mass, currently that could only be recorded in 'notes'. any benefit in making the 'number of seeds' box just 'number', and adding a 'units' box that could be 'seeds' or 'grams' (or even 'spoons')?
I agree that unnecessary constraints are annoying.
My only reluctance to change it is that it would change the scheme for existing 1.0.x database and I try not to change the schema unless the middle number changes which indicates an incompatible database.
I will definitely keep this in mind for a 1.1 series.