Milling about

mill.ipynb

@d-chambers Quick question: what is a "Mill" in this case?

@d-chambers Quick question: what is a "Mill" in this case?

Scratch that, I should read first

what is a "Mill" in this case?

You get the pun right, its not too obscure? I also thought about SawMill and Compendium

@d-chambers I would be interested to talk to you more about this at some point. I'm free this afternoon or tomorrow afternoon. A few notes:

• I know what "upsert" means (update and insert new stuff), but would it be better to just use "update"? It's a more familiar term.
• Since certain object types are explicitly tied to other objects (I'm thinking specifically of Arrivals, which are specific to the Origin... then there's the whole level of weirdness that is StationMagnitudes and StationMagnitudeContributions, how do we verify that the user is getting the objects that they want? Would the magnitude or origin id just be columns in the df? Or could there be someway to just limit them to the preferred object?
• I like the idea of using a dict for the tree structure, to eliminate awkwardness
• Is pydantic going to become a requirement for everything we do?
• I'm curious to know more about the LinkedID. Will it be used to fetch object by ID in addition to finding all objects that refer to the object with that ID? (I think you've more or less answered this? Is that what _parent is? What about objects with multiple parents?)
• On your mapping, does the stuff to the right of the = need to follow Obspy syntax exactly? If so, you are missing some get_referred_object()s. Or is it the structure you are defining with your Structures?

what is a "Mill" in this case?

You get the pun right, its not too obscure? I also thought about SawMill and Compendium

It's not too obscure once you have the context behind it. I think I might recommend something more descriptive, though.