From b8ab8db6c7cca65349fcc4e6aae020a165d5368a Mon Sep 17 00:00:00 2001 From: Alexander Schlemmer <alexander@mail-schlemmer.de> Date: Tue, 26 Apr 2022 14:52:34 +0200 Subject: [PATCH] DOC: amendments to future_caosdb.md --- src/doc/future_caosdb.md | 72 ++++++++++++++++++++++++++++++++++++++-- 1 file changed, 70 insertions(+), 2 deletions(-) diff --git a/src/doc/future_caosdb.md b/src/doc/future_caosdb.md index a34d97ef..1a68e434 100644 --- a/src/doc/future_caosdb.md +++ b/src/doc/future_caosdb.md @@ -70,21 +70,78 @@ Analogue, to what Pandas does. Provide bracket notation default attributes or contain spaces (or other forbidden characters). - Raise Exception if attribute does not exist but is accessed? -- How to deal with lists? b has a list as value: `a.b[0].c = 5` [Discussion](https://gitlab.com/caosdb/caosdb-pylib/-/issues/60) +We aim for a distinction between "concrete" Properties of Records/RecordTypes and "abstract" Properties as part of the definition of a data model. Concrete properties are always "contained" in a record or record type while abstract properties stand for themselves. + +Draft: +``` +class ConcreteProperty: + def __init__(self, v, u): + self.value = v + self.unit = u + +class Entity: + def __init__(self): + pass + + def __setattr__(self, name, val): + if name not in dir(self): + # setattr(self, name, ConcreteProperty(val, None)) + self.properties[name] = ConcreteProperty(val, None) + else: + # getattribute(self, name).value = val + self.properties[name].value = val +``` + +The old "get_property" functions serves the same purpose as the new "[]" notation. + +Instead of `get_property` / `add_property` etc. functions belonging to class Entity, we should refactor the list of properties (of an entity) to be a special kind of list, e.g. PropertyList. +This list should enherit from a standard list, have all the known functions like "append", "extend", "__in__" and allow for all property-related functionality as part of its member functions (instead of access via Entity directly). +Same story for the parents. + +**GET RID OF MULTI PROPERTIES!!!** + +#### how to deal with "property metadata" + +Current suggestion: stored in a special field "property_metadata" belonging to the object. +`property_metadata` is a dict: +- importance +- unit +- description +- ... + ### Serialization What information needs to be contained in (meta)data? How compatible is it with GRPC json serialization? ### Recursive Retrieval + + + I can resolve later and end up with the same result: `recs =db.query("FIND Experiment", depth=2)` equals `recs = db.query("FIND Experiment"); recs = resolve_references(recs, depth=2)` [Discussion](https://gitlab.com/caosdb/caosdb-pylib/-/issues/57) + +#### Alternative + +`FIND Experiment` with `depth=2` will retrieve all referenced entities from any experiment found. A typical use case could also be: + +```python +recs = db.query("FIND Experiment") +recs[0].resolve_references(depth=2) +``` + +#### Idea + +Recursive retrievel as functionality of the server. + +retrieve and query commands should support the `depth` argument. + ### In-Place operations Default behavior is to return new objects instead of modifying them in-place. This can be changed with the argument `inplace=True`. @@ -95,7 +152,7 @@ Especially the following functions operate by default NOT in-place: - resolve_references [Discussion](https://gitlab.com/caosdb/caosdb-pylib/-/issues/61) -## Extend Example +## Extended Example ``` python import caosdb as db @@ -110,3 +167,14 @@ new_one.dataset.pulses = [5, 5.3] inserted = new_one.insert() print("The new record has the ID:", inserted.id) ``` + + +### References and sub entities + +Several possibilities exist for references: + +- value is the id of a referenced entity +- value is a "sub object" +- value is a reference to another (entity-)list element (similar to second variant, but with "sub object" always contained in container/entity-list) + +To be discussed: Which should be the obligatory/preferred variant? -- GitLab