-
-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature Request - flatten collection objects #4707
Comments
I think it would be a good idea to take out specimen from the name if we could. |
coll_object.condition and ArctosDB/BackBurner#7 @dustymc said to add this here so... Let's work with condition in a similar method that we do preservation. There is no more "condition" field Everything currently there gets migrated to the condition report attribute. When entering data, the "condition" field still exists, but like preservation, it ends up as an attribute with the date stamp and determiner of the Arctos user who entered it. (Want more precision, then use the actual condition report attribute). All of the "condition" attributes are grouped together to help us review the condition history of any given part using the "Metadata" (but I'll need instruction on how to do this properly!). What did I forget? |
Wait, what? Is that what's actually going to happen? Currently UAM:EH uses that field for an overall statement of the condition (Excellent, good, fair, poor) and then we do the detailed condition report as a part attribute. Is the plan to totally get rid of the condition field? |
This is just a proposal. Clearly we will need to discuss and decide how best to do this. |
If it gets rid of some of the columns in the parts table I'd be okay in getting rid of it though. We can change as long as the info in there gets migrated into a condition report part attribute. It would save me from having to write "not recorded" in every single media condition field! |
I also like the idea in general - it's a simplification, one less way to specify condition.
Yes, this would allow for any number of assertions, and zero is still a number. |
I'm guessing this should go to the AWG now. |
AWG asks that we be able to create new condition attribute(s) from the loan form. |
I still have questions before this can go next task. FOR PARTS:
Do we need to record entered and edited for parts? (My vote: Nope, I don't think anyone's ever asked for that, I think that can be moved completely to cataloged items.)
Actually can we just get rid of this? Maybe move whatever's there to https://arctos.database.museum/info/ctDocumentation.cfm?table=ctattribute_type#processing_history? If anyone wants something similar for parts they can request a new part attribute.
Is there any reason to do anything new and different with these? (I don't see one.)
I think this hasn't been exposed and holds nothing of value, suggesting finding a place (https://arctos.database.museum/info/ctDocumentation.cfm?table=ctspecpart_attribute_type#location perhaps) for whatever's in there if anything is and dropping the concept.
rename to 'part_remark' (unless someone has better ideas) FOR CATALOGED ITEMS
Do we still need that, do we need something different, ????
rename to - uhhh - help! cataloged_item_remark?? record_remark? item_remark?? TODO Figure out what's in condition history, make a lot of attributes or concatenate it with current condition into the one new attribute or ??? Need to pull data, then discuss. (ditto disposition_remarks, see above) CLARIFICATION
I think it'll just be any new part attribute(s) - https://github.com/ArctosDB/BackBurner/issues/7 should use https://arctos.database.museum/info/ctDocumentation.cfm?table=ctspecpart_attribute_type#tissue_quality and/or https://arctos.database.museum/info/ctDocumentation.cfm?table=ctspecpart_attribute_type#storage_temperature instead of the generic descriptive option, for example. |
HMMMM - I say we keep it because eventually someone is going to ask "who the heck added 500 parts to my collection and why?". |
What's in there now? |
Agree - these are fine as they are. |
What is in there and how did it get there? |
It's a fair bit of data for which we pay in performance and storage. Definitely a cost we can pay if we must, but I'd prefer not to get too theoretical here. The flat edit history mentioned in the initial comment is more than capable of getting at someone adding 500 parts. |
Yes, please. Do we actually have two things called coll_object_remark.coll_object_remarks? Should all the part stuff be renamed so that it is less confusing? (Maybe that's crazy though...) |
So this stuff is about the ENTIRE record, correct? I am in favor of only looking at last edited in one way, so as long as everyone can figure out who edited stuff and when with flat edit history, then let's simplify? |
No, but it's not flat. (So there's one, or there's at least one, or there's as many as you need, depending on your perspective.)
That's what @ewommack suggested. It would add work, maybe quite a bit, but there will probably never be a better time. |
The obstacles are gone, proceeding with this, there's important stuff in the first comment. |
AWG - no overwhelming support for doing anything clever with condition, move it straight across |
AWG: last edit isn't useful, cache and drop (and maybe we need a focus group to find some actually-useful 'edited'). |
I am splitting loan_item.collection_object_id into loan_item.part_id and loan_item.cataloged_item_id. Everything involving loan items should be checked. |
Unless someone has immediate and compelling reasons not to, I think I'll rename some of the coll_obj.... things - starting with https://arctos.database.museum/info/ctDocumentation.cfm?table=ctcoll_obj_disp - while I'm rebuilding kinda everything anyway. |
Is this related to the Parts View/Download issue, where the view version shows Part Remark but the download version calls same content Collection Object Remarks? |
Essentially everything - anything that touches involving parts, catalog records, or loans - has been revised in test (https://arctos-test.tacc.utexas.edu) and should be tested. |
Whats the deal with the little box after the part name in a loan? https://arctos-test.tacc.utexas.edu/loanItemReview.cfm?transaction_id=21112061 |
fair - possible to put some standard thing when there are no attributes so it doesn't look weird? "no attributes" OR just leave it off if there are none? |
Definitely not from here... "Looks weird" is a feature - it should be obvious when there are no attributes vs. when they're not shown in this format. |
Per #4707 (comment) here's last edit data for cataloged items: |
Per #4707 (comment) here's last edit data for parts: Err, nope, it's too big and won't attach, it's on my drive and the test VM, ping me ASAP if anyone wants a copy. @mkoo maybe you have a place for a 30MB file? |
Upload it to TACC? Sounds weird, but isn't that what we have storage there for? |
I think it's all garbage (that's why we're unloading it!) and don't really want to put that in archival storage.... |
disposition_remarks cache: |
EDIT: Here's a migration path spreadsheet summarizing the conversation below: https://docs.google.com/spreadsheets/d/1jfCdsMV4e4dDU-G1guYbyLBqTfuPSNZB_1zjDXol8NU
dependencies are
#6297
#6691
Original below
Is your feature request related to a problem? Please describe.
From #4706, the join to coll_object is surprisingly slow and hard to tune
Describe what you're trying to accomplish
Go fast.
Describe the solution you'd like
There are now only two types of collection objects in Arctos, and I can't envision having more. They're very different shapes, and I don't think there's any real reason to normalize the core. (Both need to join to table coll_object, but not everything in there is appropriate to both.) I don't think there's any obvious drawback to flattening, and doing so should simplify the model and make things a bit faster. Specifically,
*coll_object. last_edit_date (or not? Flat edit history is about the same thing with more info)
and rebuild everything to use that simplified structure
Describe alternatives you've considered
Keep on keeping on.
Additional context
Priority
Lowish, probably; might be higher if the potential performance impact was better understood.
The text was updated successfully, but these errors were encountered: