partkeepr
Storage Locations
Hi felicitus, thanks for all the work you've put into PartKeepr!
I've seen your recent implementation of Storage Location Categories (#225). This looks nice and is useful in many cases, but it doesn't solve all problems related to the Storage Locations (and there are still a lot of open issues concerning them). For example, in reality I have a layout like this (shortened version :wink: ):
- Hobby room
- White cupboard
- Shelf 1
- Oscilloscope
- Curver Box 1
- Network cables
- Curver Box 2
- ESD-box 1
- microcontrollers
- ESD-box 2
- opamps
- ESD-box 1
- Shelf 2 ...
- Shelf 1
- White cupboard
The current solution in PartKeepr would be, to give all Storage Locations 'absolute path' names, for example HobbyRoom_WhiteCupboard_Shelf1_CurverBox2_ESDbox1. I would rather not use that solution, because it is very unlogical, and it will take a lot of effort. For example, moving Curver Box 2 to a different shelf has quite some impact: all ESD-boxes in this crate must be manually renamed to reflect the new shelf!!
Can this problem also be solved by using Storage Location Categories? In that case, the 'normal' items would be Storage Location Categories, the Italic items would be Storage Locations, and the Bold items would be Parts. But that won't work, because I cannot put the oscilloscope directly on Shelf 1, since the shelf is a Category, not a Location... Furthermore, I cannot move the cardboard ESD-boxes into Curver Box 1, because that box is a Location, not a Category... The network cables cannot go directly into Curver Box 2 since this is a Category :confused:
I would like to propose a (relatively easy?) conceptual change, which would solve this and some related problems at once. The basic idea is: a Storage Location can also be stored inside another Storage Location!
- Give the Storage Location object one new data member: its parent Storage Location
- The default value of this member (NULL, or maybe some 'Root Storage Location' object) will indicate that the Storage Location is not stored within another Storage Location. --> This makes it fully backward compatible for current data sets, and for people who don't want to use it!
- A Storage Location should only store its relative name (example: Curver Box 2). The full Storage Location Path can be easily found by walking the tree upwards, concatenating the name of each parent Storage Location encountered, until the NULL or 'root' pointer is found. In my example, the full name of the Storage Location of the opamps would be Hobby room/White cupboard/Shelf 1/Curver Box 2/ESD-box 2.
- If no nesting is used, the full name equals the name of the Storage Location, making it fully compatible to the current situation (i.e. people can keep using the 'absolute location' naming method).
- When Storage Locations are modified by the user, a check is needed, so that the location does not become circular. For example: traverse the path up to the root and check that the location does not already exist in the path somewhere.
- A Storage Location can now contain both Parts and other Storage Locations, so the Storage Location overview in the GUI must be modified to reflect that.
Now, moving a box (with all its contents!) becomes as easy and intuitive as one would expect: change the (parent) Storage Location of Curver Box 2 from Shelf 1 to Shelf 2! :smile: I can store my scope directly on a shelf, since all objects in the tree are Storage Locations! I could even throw all opamps on the carpet (I wouldn't), because Hobby room is also a storage location! :grin:
The Storage Location Categories functionality is now freed up to be used in more useful ways, for example:
- Box
- small box
- large Curver box
- cardboard ESD-box
- Shelves
- Full shelves
- shelves with room available etc.
Please give this idea a thought, I hope you'll see its potential. It might solve other issues as well (for example #664 and #413).
Thanks for your time, I appreciate it (it was a long read, sorry for that). With kind regards,
Matthijs
Agree fully, I also have a room full of parts, and would benefit from an organisation system like this.
WARNING: This design is not complete, or well thought through. It's late at night and I may have been drinking a little.
In fact, it should be pretty easy to implement. I wouldn't complete the task using parent/child relationships exclusively. I would consider a pool of storage resources, which can be anything from a Part, to a Storage Bin, to shelving units, to whatever. I would allow items to have parents, as well as a pointer to a location. This decouples main storage (shelving, shelf divisions, etc) from discrete storage units, such as a 'storage bin' this limits the hierarchy walking required, and simplifies the problem to a 'real world' based model design.
StorageLocation
- Hobby room. This is your root. There can be more than 1 root.
- meta about the location
- contain a collection of StorageContainers, and their locations in the room
StorageContainer
- Shelf, Bin, box, plastic bag, whatever. This becomes the smallest storage item.
- has a collection of IStorable
StorageContainer, StorageUnit, Part implement IStorable.
IStorable
- marker interface to identify a storable item.
StorageUnit -> Actual storage locations. May be subclassed for specialized containers if necessary. drawers, shelves, divisions of other locations, or whatever. Certainly can be templated for reuse.
StorageLocationCategory -> becomes a tag, not a parent. storage locations can have many categories.
DefaultStorageContainer extends StorageContainer
- maybe a standard bin, rows, columns, tray depth location details added.
ShelvingUnitContainer extends StorageContainer
- Maybe just rows, and columns? not sure if this is needed
HobbyRoom extends StorageLocation- the true root container, if necessary. Some people have more than 1 place they store stuff.
Templates! Once you have a nice box constructed, save it. deploy it as many times as you want. I have 9 of one type of bin, 6 of another, etc. Sure would be easier to just create a whole customized bin. A suite of default storage locations and location builders would cover most peoples needs right out of the box.
I may be going a bit far with the subclassing, but the core model presented is reasonable. With a bit of work on the design of the model elements, a robust storage system can be created that's very flexible, and won't have to be re-visited in the future. Strait up tree hierarchy doesn't reflect the real world model of the problem we are trying to solve, hence the issues making the solution fit a wide range of needs..
The solution is close enough to the existing product, that a migration script could be deployed to move people between versions.
I can only agree, I was surprised to see that there is no way to define a rack of storage boxes. InvenTree seems to have implemented nesting already (https://inventree.readthedocs.io/en/latest/stock/stock/), which could be a nice reference.
Just for clarification, isn't this pretty close to https://github.com/partkeepr/PartKeepr/issues/225? That one seems to be done already.
I would also add that I have a need to specify a location similar to a part, e.g. "box of JST connector that I bought at x". Adding it as a single part works, but prevents content awareness, e.g. searching for all 3-pin JST.
