Define product/order data models

[orthecreedence]

• [x] Create product model
• [x] Create order model
• [x] Create order cost model (snapshots costs into an order)
• [x] Create product cost model, attaches to product

Products

• Break products down into their parts (company, name, details, ...)
• Define a way to attach variant information (stock numbers, location, etc) to each product such that products are mostly static and data about them is what changes
• Define product variants..."Red Rhino tshirt" is the product, the variants are S, M, L, XL...
  • "Effort" values apply to variants
  • Variants hold the physical attributes (solid, liquid, unit of measurement, dimensions, etc)
  • The idea is you might have "89 octane gasoline" product, then a "89 gas 5gal container" or "89 gas by the liter delivered by tanker semi"...same product, physical attributes attached to variants.

Orders

• Orders connect two companies (a third if shipping is involved)
• Orders operate on product variants, not products

Orders are not just the intent, but also the event that triggers the attachment of the disaggregate "costs" of inputs, labor, etc onto the products as a function of that order. In other words, I order 10 widgets, once those widgets are complete, the order doesn't just describe the 10 widgets, but also the inputs, labor, and other costs associated with those widgets attached to each widget such that each widget will have 1/10 of all the data attached to it.

This way, orders are a "freeze frame" of those products and memorialize the data making up their production.

Shipping

Moved to issue #19 (and punting until after v0.1)

---

Models should reflect the anarcho-communist principles of this project, not the Basis <--> market interfacing (in other words, we are building this assuming the entire economy is using it and markets are no more).

[orthecreedence]

unassigned @orthecreedence

[orthecreedence]

assigned to @orthecreedence

[orthecreedence]

mentioned in commit basis@ff9267aa4474dc895aa3627863213332dfcb57a4

[orthecreedence]

changed weight to 10

[orthecreedence]

changed weight to 5

[orthecreedence]

mentioned in commit basis@a482a7be256a727471be62ba96428893c5db7ddd

[orthecreedence]

mentioned in commit basis@3c055e5ffb8ea6960f50975394b47a2b31924e5f

[orthecreedence]

As I'm building this out I'm realizing just how complicated the cost tracking might be, so I'm going to probably prototype this in JS and move to rust once I'm happy. I've redefined this model like 10x already. I'm fairly satisfied with the product model, but orders and shipping really need some clear thought. Mainly orders, because they are the vehicle for cost tracking and I'm not sure how that looks yet.

[orthecreedence]

removed the weight

[orthecreedence]

I'm waffling back and forth on not even modeling in cost tracking in the products themselves

Attaching cost information directly to products

Pros:

• Computationally much cheaper to query costs because each product contains them (cached)
• More secure: if the blockchain itself calculates costs and caches them, there is less ability to corrupt the data, as opposed to some separate costing server that hopefully uses the blockchain's data without altering it
• Algorithms for determining costs deal only with inputs and outputs at the node (company) level and are therefor much simpler

Cons:

• Data corruption: if there's a bug in the cost tracking, it could cascade for years
• Rigidity: if multiple methods of cost tracking become available (for instance a new algorithm to handle depreciation) then the old data becomes obsolete
• Need some triggering event to update the costs of a company's products (order/clock-in, maybe?)

Calculating costs after the fact (either on-demand or via some kind of graph database)

Pros:

• Bugs in calculation do not persist in data indefinitely
• Calculation methods can be changed/updated nearly instantaneously
• Simplicity of tracking: only need to model comapnies, products, and orders and the rest can be calculated after the fact

Cons:

• Computationally expensive to determine costs. Economic networks are vast and would require immense amounts of traversal, even for just one product.
• Harder to calculate things like loops (plumber buys pencils from the pencil company that uses the same plumber to fix their pipes)
• Is this even practically possible? If each consumer and each producer is making dozens of decisions a day on costs, then there's no way the costs could be calculated on-demand. Either way it requires some kind of caching, and if that's the case, it requires some kind of storing of calculated data.

---

Ok, thanks, pros and cons list. Calculating costs after the fact seems much more like kicking the can down the road than it does "Aha! I've solved it!" In fact, calculating after the fact would necessitate some kind of caching layer anyway if it was to be practical, so no matter what you'll have the possibility of stale data.

Also, the more I think about it, the more I'm realizing that the algorithm can be updated, and will adjust over a much shorter period of time than the "years" I quoted above.

It's seeming more and more like, yes, you should definitely store the costs of products and services directly with them (or as some form of linked cost-attachment object).

[orthecreedence]

Happy day: just merged the cik branch into `master on https://gitlab.com/basis-/product-costs.

Now it's a matter of adapting the algorithm to encompass real orders instead of fake test data! This is a great step forward for the project.

[orthecreedence]

ok, so every time there is an order or clock in/out, we're going to readjust the product costs. however, this doesn't mean it's easy to get the product prices for each order. there are two options.

1. store the product prices in the order itself.
2. store the log of product price changes with the company, indexed by date.

the first option is the easiest, but takes a lot more storage. really, since orders are going to be the most numerous object, i want to keep them as lean as possible.

the second option keeps orders leaner, but is a bit more query time when creating the order.

???

might start off putting the costs into the order itself because this is a proof of concept, then switch it to something more efficient later.

[orthecreedence]

Closing this in favor of #23 since we've broken the pieces out a bit more. This was mostly a discussion issue and it has served that purpose quite well, even if I was the only one engaging in discussion. Now we have a more solid plan, so we'll leave the talk to the politicians.

[orthecreedence]

closed