Ferreteria/v0.42/odata

versions: 0.41, 0.42, 0.5

About

Each Template:L/version represents the core of a pseudo-record, which can have an arbitrary set of fields (leafs). Each Template:L/version (field within a p-record) must have a unique name.

There is a registry, maintained by code, of pseudorecord types (node.Type). This is so the code can look up the proper class to use for handling each node (pseudorecord). It remains to be seen if this part works as envisioned.

Pages

• tables:
  • Template:L/version: core pseudorecord
  • Template:L/version: field within a pseudorecord

Background

This system is experimental, and replaces/updates the old content system (which was really part of 0.2 or 0.3). It's a simplification of v0.41, which was designed as far as schema and some code but ran into coding difficulties when trying to use the system for event logging. The problems were solvable, but a simpler design seemed like it would represent much less technical debt.

Notes

2021-01-20

Usage:

\fcApp::Me()->LogData()->CreateEvent(
          KS_EVENT_FERRETERIA_SENDING_ADMIN_EMAIL,
          $arEv
          );

2020-02-03

In the previous version of the event logger, when I logged changes to a record, there were fields where I stored a serialization of the old and new values:

  [stash.before] =>     (array) : 7 elements
    [ID] =>     (string) : 15
    [Name] =>     (string) : Zion Rootswear
    [ID_Topic] =>     (NULL) : 
    [ID_PriceFunc] =>     (string) : 10
    [CatKey] =>     (string) : ZR
    [isActive] =>     (string) : 1
    [Notes] =>     (string) : This is test note #2.
  [stash.change] =>     (array) : 6 elements
    [Name] =>     (string) : 'Zion Rootswear'
    [ID_Topic] =>     (string) : NULL
    [CatKey] =>     (string) : 'ZR'
    [isActive] =>     (string) : 1
    [ID_PriceFunc] =>     (string) : 10
    [Notes] =>     (string) : 'This is test note #2.'

(Optimization Squirrel wants to deduplicate that, of course -- but Debugging Squirrel says if you're fixing a bug, you can't trust deduplication code, so best to be safe, at least until the system feels like it has passed the test of time.)

The default/easy-ish solution would be to just keep doing that -- serialize the array and stash it in a single Leaf.

...but a better solution would be to implement a little bit of hierarchy -- the "before" and "change" stashes should really each be their own Nodes, so each field can be a Leaf.

The question is which of at least 2 possible methodologies do I use for implementing hierarchy. None of them are obviously bad or obviously best.

• Method A: Every Node record has an ID_Parent field
• Method B: Code can add ID_Parent Leafs as needed, and ID_Before and ID_After Leafs to the parent-Node for easier data-finding
• Method C: a Node_ship ("ship" being, of course, short for "relationship") table which can store information about all kinds of relationships between Nodes

A

• what: Every Node record has an ID_Parent field.
• positives: simple
• negatives:
  • adds a field to every Node that will only sparsely be used
  • restricts relationships to being hierarchical
  • generally is a move back towards a less-flexible system with dedicated fields for event data

B

• what: Code can add ID_Parent Leafs as needed, and ID_Before and ID_After Leafs to the parent-Node for easier data-finding.
• positives:
  • no schema changes needed
  • does not take up space when not used
• negatives:
  • may be slow/inefficient
  • intuitive objection: may lead to sloppy code design (too flexible?)

C

• what: a Node_ship ("ship" being, of course, short for "relationship") table which can store information about all kinds of relationships between Nodes
• positives: conceptually simple, flexible, probably fastest & most efficient
• negatives: requires new table, classes to match, and all the coding complexity & technical debt that inevitably entails

Evaluation

Definitely liking B or C better, but which one is best...

Argument for B: doing C involves making some additional decisions about the table design. Possibly that should wait until we have more usage-cases to base it on.

(Ultimately decided on B for now, will do C at some later time if it still seems like a good idea.)