[Feature] Filament Management

[jichengzhi]

The lab manager wants to track filament usage, currently everything is logged manually, for example:

• information of filament (in packs)
• when and who used a specific pack of filament
• how much filament is consumed by a printing job

[jichengzhi]

Proposed ERD from @jon65 and @shiki65536

[jichengzhi]

1. use saturated key if PK of your table is composed by multiple columns. This is good for REST APIs, for example filaments/history/1 will get a filament status history record whose id is 1, but you can't do that if you use status_id and timestamp as PK.
2. in the filament table, is opened_by a FK to the user table?
3. is it appropriate to record assigned_to and opened_by in the filament table?
   • in my opinion, a filament row represents a filament pack. The usage history should be recored in the history table
   • also, I think opened_by is same as filament_status_history::action = 'open'
4. please do not modify the existing printing job table because it ONLY records info about the printing job status. Add a job_filament table to record filament usage of the job, and add a job_id to refer to the printing job

[shiki65536]

Thank you for your guidance and explanation.

• About point 1. The reason that we discussed about timestamp as PK was some teams may prefer using less keys. timestamp is usually unique enough but not clean so we came out with status_id.
  We were not sure which one our team prefer so glad to know the feedback.

• About poinrt 2, 3, 4 Roger 2, 4, agree with 3.

• Another issue We also discussed should PrintJob and Filament be a multiple to multiple relation. I think PrintJob can reach the filament info through printer so it might not necessary, but we are not sure.

[jichengzhi]

Thank you for your guidance and explanation.

• About point 1. The reason that we discussed about timestamp as PK was some teams may prefer using less keys. timestamp is usually unique enough but not clean so we came out with status_id. We were not sure which one our team prefer so glad to know the feedback.
• About poinrt 2, 3, 4 Roger 2, 4, agree with 3.
• Another issue We also discussed should PrintJob and Filament be a multiple to multiple relation. I think PrintJob can reach the filament info through printer so it might not necessary, but we are not sure.

A timestamp is not unique in distributed system. If I have 2 printing servers (which I will do due to limited performance of PIs), they may insert data at the same time.

If a printing job may involve one or more filaments, the relationship is many to many:

• a job can have 0 (not printed) to many filament records
• a filament may be used to print 0 to many jobs

[jon65]

Thanks @jichengzhi for uploading the design and sorry for my inactivity lately. Will be more responsive from now on.

Based on your comments I have updated this design,

1. Could you explain what do you mean by saturated keys? Do you mean to use a single surrogate (self defined) key like filament_history_id?

2. From my understanding filament_status_history has a M-M relationship with filament (represent when a user load/unload a filament) but opened_by and assigned_to has a 1-1 relationship with filament. I created a seperate filament_responsibility table to solve this.

3. Noted, I created job_filament below

1. use saturated key if PK of your table is composed by multiple columns. This is good for REST APIs, for example filaments/history/1 will get a filament status history record whose id is 1, but you can't do that if you use status_id and timestamp as PK.
2. in the filament table, is opened_by a FK to the user table?

3. is it appropriate to record assigned_to and opened_by in the filament table?

   • in my opinion, a filament row represents a filament pack. The usage history should be recored in the history table
   • also, I think opened_by is same as filament_status_history::action = 'open'
4. please do not modify the existing printing job table because it ONLY records info about the printing job status. Add a job_filament table to record filament usage of the job, and add a job_id to refer to the printing job

[jon65]

for FILAMENT_STATUS_HISTORY table, do you think it is better to do this design? Might be more intuitive for users to track because load/unload is combined into 1 record.

[jichengzhi]

Thanks @jichengzhi for uploading the design and sorry for my inactivity lately. Will be more responsive from now on.

Based on your comments I have updated this design,

1. Could you explain what do you mean by saturated keys? Do you mean to use a single surrogate (self defined) key like filament_history_id?
2. From my understanding filament_status_history has a M-M relationship with filament (represent when a user load/unload a filament) but opened_by and assigned_to has a 1-1 relationship with filament. I created a seperate filament_responsibility table to solve this.
3. Noted, I created job_filament below

1. use saturated key if PK of your table is composed by multiple columns. This is good for REST APIs, for example filaments/history/1 will get a filament status history record whose id is 1, but you can't do that if you use status_id and timestamp as PK.
2. in the filament table, is opened_by a FK to the user table?

3. is it appropriate to record assigned_to and opened_by in the filament table?

   • in my opinion, a filament row represents a filament pack. The usage history should be recored in the history table
   • also, I think opened_by is same as filament_status_history::action = 'open'
4. please do not modify the existing printing job table because it ONLY records info about the printing job status. Add a job_filament table to record filament usage of the job, and add a job_id to refer to the printing job

1. Sorry for the typo, I meant surrogate key.
2. The relations are correct, but I think it's better to use table name filament_loading_history instead of status_history since opening and assignment are also status changes.
3. I think filament_responsibility is redundant because it is duplicating data from the filament table. The previous design is good for me

[jon65]

3. Made a typo in my design, I moved opened_by and assigned_to from filament -> FILAMENT_RESPONSIBILITY.

[jon65]

corrected design: