Quantity needs units and fuzzy support

[cwyse]

Especially for seeds, when I need to enter a quantity for an accession, I'm not sure of the exact number. Maybe I got 1 gram of seeds. Maybe I have a handle of seeds, and I think I have about 100 seeds. I'd like to have an option to enter units and a way to indicate an inexact amount.

[mfrasca]

@RoDuth, IIRC you had this problem in Australia, I don't remember how you solved it. by adapting your practice, by altering the software locally, you want to remind me and tell @cwyse ?

[RoDuth]

We had originally been using things like '30+' which were allowed with sqlite but when trying to import into postgresql this failed. We then realised that if we knew the exact amount it was almost never multiples of 10 like this so we just started using multiples of 10 as a convention for estimated numbers (be they clumps, hedges, border plantings, etc.) and including a note, something like type: "quantity" note: "hedge". On the odd occasion it was actually 10 and not an estimate it was easy to see there was no note.

On a side note I have been looking at our seed bank records (currently not in Ghini) and we have a fairly strict way to come up with numbers (basically, count out a portion and compare the weight to the whole) and they are the same, almost never multiples of 10.

In your situation you could include a note, something like type: "accuracy" note: "+/-20" I guess?

[mfrasca]

@cwyse , as you see, it's a bit adapting to the limitations in the software, and it's good that you mention what you miss, so we can add it in a future version. The reason why I did not add it to 1.0, it's very simple: it would mean a change in the database structure, and in ghini.desktop a database structure corresponds to a software version. in ghini-reloaded it's possible to add it in the same version, because django has built-in migrations.

[cwyse]

Thank you both for responding. @RoDuth had the exact same problem that I did, and implemented basically the same solution.

My thought was that adding two columns to the database would address the problem. One column for the units, and one column indicating accuracy. Probably oversimplifying, but I'm guessing that the column addition (instead of removing, changing, or adding a new table) would maintain compatibility with older versions.

Anyway, it's a low priority item for me.

[mfrasca]

On 08/04/2020 07:58, cwyse wrote:

Probably oversimplifying, but I'm guessing that the column addition (instead of removing, changing, or adding a new table) would maintain compatibility with older versions

remember that we have a database abstraction layer, where the database structure is described.

when you write compatibility, it's really two different situations:

new software with old database.  this will not work, full stop. the database abstraction layer 'DAL' will find a non-matching database, and it should simply fail, that's the only safe thing to do.

new database with old software would work (as you say, we add, not remove/change columns, so the DAL will not notice the extra columns and be happy with what it does find), but this will create space for semantic mistakes in the data, like you not seeing the data unit, and correcting a 3 (grams) to 400 (seeds).

taken together, they form the reason why we have a database version number in the metadata table.

[cwyse]

Definitely should have a database version. I defer to you on how complex the problem is - I haven't gone through the code base. It was a suggestion, but the cost/benefit ratio may not merit working on it. Thanks for looking at it.

[mfrasca]

I'll re-open this one, because it's not solved, and it could be better documented too.