Donkie / SpoolmanDB

A centralized place to store information about 3D printing filaments and their manufacturers
MIT License
22 stars 10 forks source link

Database Schema Refinements #32

Open YanceyA opened 1 month ago

YanceyA commented 1 month ago

As people have started entering more filaments into the database there are have been some important findings and questions on how to enter some filament specific information. There is also a question on whether this information is important to be included in the data base to allow for categorization.

The goal is to have a bit of architectural discussion, discover additional areas to cover, and hopefully make PRs for a stable JSON schema. It seems that continuously litigating JSON schema changes is risky for database stability, uncertainty for data entry, inconsistent data entry.

As defined on the readme page "A centralized place to store information about 3D printing filaments and their manufacturers." seems to imply, to me, that we are looking for a detailed database with lots of categories and details of filaments. However, this type of detailed database doesn't necessarily align with the core needs of a maker using Spoolman to catalog and maintain their physical spool library and support actual 3D printing.

A non exhaustive list of open questions:

Fills [see https://github.com/Donkie/SpoolmanDB/pull/21 ]

Glitter [see https://github.com/Donkie/SpoolmanDB/issues/31 ]

Refillable Spools [ https://github.com/Donkie/SpoolmanDB/issues/26 ]

Material Names [ https://github.com/Donkie/SpoolmanDB/pull/15 , https://github.com/Donkie/SpoolmanDB/pull/9 ]

Distinctive filament properties

Nylons or Polyamides [ https://github.com/Donkie/SpoolmanDB/pull/15 ]

TPU:

References:

https://www.findoutaboutplastics.com/2020/12/plastic-part-marking-overview-codes-and.html https://drive.google.com/file/d/1fIG9HlW-9AiyGDQsstiNUaXkKw-1Cyle/view

Keridos commented 1 month ago

I'd add glitter to the fills section. Fills should be an array in case of multiple fills being present.

Fill object should be an object like:

fill-name:
  type: required
  color: optional
  size/length: optional
  fill_ratio: optional (because it can be unknown)

For TPU, I'd propose sticking to one standard and then standardizing it so it is "TPU-##A" to prevent confusion. Regex that would be something like TPU([0-9]{2}A){1}

Special Filaments I would only broadly categorize those that with f.ex. cleaning filament mixed filaments (PC+ABS f.ex.) flame retardant, though that could simply be an attribute for generic filament support filaments, though that could be filament types, too aero/lightweight

I think for the more esoteric filaments users should define them themselves, since you can also add custom attributes.

StuSerious commented 1 month ago

https://regex101.com/r/SedDNb this is the current regex for matching material names, ad you can see it matches both shore A and D ratings ;)

Donkie commented 1 month ago

I think my idea has been to support as much structured data as possible in the database, but only things that are necessary for Spoolman are required fields, such as density and spool weights etc.

At the same time, if we make the structured data too detailed then it just becomes too much of a chore to add. Fill for example could be enough to just specify fill type as we have now, and maybe color. But on the other hand, fill color could be just as well specified in the filament color name itself. Specifying fill size and ratio is just way too detailed and I don't think anyone would search for exact quantities like this.

On another note:

I think having a GUI would make life easier for people to maintain this database, and I've been thinking of ways of doing that but haven't really come up with a good idea. I like the way it works now with people submitting PRs because it means we can utilize Github's built-in review functionality and don't need to create a new one. But then how to make a GUI that lets people edit the .json files and then submit as a PR? This is probably for a separate discussion though...

Keridos commented 1 month ago

At the same time, if we make the structured data too detailed then it just becomes too much of a chore to add. Fill for example could be enough to just specify fill type as we have now, and maybe color. But on the other hand, fill color could be just as well specified in the filament color name itself. Specifying fill size and ratio is just way too detailed and I don't think anyone would search for exact quantities like this.

Well, the ability to define what type of infill it is and assign that specific infill a color would be nice. I agree that we should not overengineer too much, though.

I think having a GUI would make life easier for people to maintain this database, and I've been thinking of ways of doing that but haven't really come up with a good idea. I like the way it works now with people submitting PRs because it means we can utilize Github's built-in review functionality and don't need to create a new one. But then how to make a GUI that lets people edit the .json files and then submit as a PR? This is probably for a separate discussion though...

Github offers codespaces so you can easily make changes in your browser with a web vs code session. Works pretty good for me, when I do not wan't to clone the repos to my computer.

StuSerious commented 1 month ago

I think having a GUI would make life easier for people to maintain this database, and I've been thinking of ways of doing that but haven't really come up with a good idea. I like the way it works now with people submitting PRs because it means we can utilize Github's built-in review functionality and don't need to create a new one. But then how to make a GUI that lets people edit the .json files and then submit as a PR? This is probably for a separate discussion though...

It would be amazing to add a tab to Spoolman's frontend where a user could either automatically submit their library or graphically input values to be converted in the JSON schema format.

Such an implementation is way above my head, as I have little experience with TS, but I could give it a shot. @Donkie if you're fine with a fair amount of hand-holding and reviewing I could try and submit a PR.

Donkie commented 1 month ago

I think having a GUI would make life easier for people to maintain this database, and I've been thinking of ways of doing that but haven't really come up with a good idea. I like the way it works now with people submitting PRs because it means we can utilize Github's built-in review functionality and don't need to create a new one. But then how to make a GUI that lets people edit the .json files and then submit as a PR? This is probably for a separate discussion though...

It would be amazing to add a tab to Spoolman's frontend where a user could either automatically submit their library or graphically input values to be converted in the JSON schema format.

Such an implementation is way above my head, as I have little experience with TS, but I could give it a shot. @Donkie if you're fine with a fair amount of hand-holding and reviewing I could try and submit a PR.

I'm a bit against having people sync their local spoolman library automatically to this database, since the quality of the data can be a bit hit and miss. It also would mean fields like fill type etc won't be added automatically since Spoolman doesn't have such fields built in.