Ferreteria/archive/v0.5/sql/node leaf: Difference between revisions

From Woozle Writes Code
Jump to navigation Jump to search
(Created page with "==About== * '''Purpose''': Values for nodes ==Concept== Every '''leaf''': * has ** a data type ** a name (unique within the node) ** a value * is like a single field in a sing...")
 
No edit summary
Line 1: Line 1:
'''versions''': {{l/ferreteria/|v0.42/sql/node_leaf|0.42}}, {{l/ferreteria/|v0.41/sql/node_leaf|0.41}}
==About==
==About==
* '''Purpose''': Values for nodes
* '''Purpose''': Values for nodes
Line 4: Line 5:
Every '''leaf''':
Every '''leaf''':
* has
* has
** a data type
** a name (unique within the node)
** a name (unique within the node)
** a value
** a value
* is like a single field in a single record
* is like a single field in a single record
==Fields==
==Fields==
* '''Type''': name of type; caller code will maintain an index of leaf-handler classes (<code>array[Type] => class_name</code>)
==History==
==History==
* '''2017-08-03''' Started, because the need became apparent.
* '''2017-08-03''' Started, because the need became apparent.
Line 18: Line 17:
** Turns out LONGTEXT [https://stackoverflow.com/questions/10957238/incorrect-string-value-when-trying-to-insert-utf-8-into-mysql-via-jdbc barfs at certain kinds of binary data], so changing to LONGBLOB.
** Turns out LONGTEXT [https://stackoverflow.com/questions/10957238/incorrect-string-value-when-trying-to-insert-utf-8-into-mysql-via-jdbc barfs at certain kinds of binary data], so changing to LONGBLOB.
* '''2022-03-06''' copying {{l/ferreteria|v0.42/sql/node_leaf|v0.42}} verbatim for v0.5
* '''2022-03-06''' copying {{l/ferreteria|v0.42/sql/node_leaf|v0.42}} verbatim for v0.5
** "Type" is in the documentation but not the table design. I'm thinking that it should be defined by the code, which will determine the data format based on registered field names. When we want to implement searching, there can be a separate table for indexing individual field-types.
==SQL==
==SQL==
<syntaxhighlight lang=mysql>CREATE TABLE `node_leaf` (
<syntaxhighlight lang=mysql>CREATE TABLE `node_leaf` (

Revision as of 17:38, 6 March 2022

versions: 0.42, 0.41

About

  • Purpose: Values for nodes

Concept

Every leaf:

  • has
    • a name (unique within the node)
    • a value
  • is like a single field in a single record

Fields

History

  • 2017-08-03 Started, because the need became apparent.
  • 2020-01-16 redesigning for v0.4 (copied from Ferreteria/sql/tf leaf) - this became 0.41
  • 2020-01-23 tweaking for v0.42
  • 2021-01-19
  • 2022-03-06 copying v0.42/sql/node_leaf verbatim for v0.5
    • "Type" is in the documentation but not the table design. I'm thinking that it should be defined by the code, which will determine the data format based on registered field names. When we want to implement searching, there can be a separate table for indexing individual field-types.

SQL

CREATE TABLE `node_leaf` (
  `ID`      BIGINT        NOT NULL AUTO_INCREMENT,
  `ID_Node` BIGINT        NOT NULL COMMENT "ID of node to which this value belongs",
  `Name`    VARCHAR(255)  NOT NULL COMMENT "field name of this value",
  `Value`   LONGBLOB  DEFAULT NULL COMMENT "value",
  PRIMARY KEY(`ID`),
  UNIQUE KEY(`ID_Node`,`Name`)
) ENGINE=InnoDB;