Ticket #1089 (closed Feature Request: fixed)
Identity-Value data model
Reported by: | jri | Owned by: | jri |
---|---|---|---|
Priority: | Major | Milestone: | Release 5.0 |
Component: | DeepaMehta Standard Distribution | Version: | 4.8.8 |
Keywords: | Cc: | Malte, JuergeN, dgf, robert.schuster | |
Complexity: | 13 | Area: | Data Model |
Module: | deepamehta-core |
Description
A type is either an identy type or a value type.
The instances of value types are immutable.
The instances of identity types are updated in-place.
Value types can be simple or composite.
Identity types can be simple or composite.
Value types can have both, value child types, and identity child types.
Identity types can have both, value child types, and identity child types.
Examples:
"Address" is a value type. An address never changes. If a person's address changes the person is assigned to another (possibly newly created) address object.
"Person" is a identity type. If the address of a person changes, the person remains the same. It keeps its identity. No other person object is created.
Objectives:
- Object sharing
True semantic objects: things like Names, Adresses, Dates, Times, Geo Coordinates, ... exist only once and are shared among many composites. They are never changed in-place. Updating arbitrary complex composite structures causes no semantic side effects.
- Simpler frontend develoment
The data-update intelligence moves from client to server. The process how new data is integrated with existing data is governed by the server. The client fetches a composite object from the server, updates it (through client-side data-binding), and sends it back to the server. The client is not required to send IDs or refs. It just sends values.
Change History
comment:5 Changed 7 years ago by Malte
Hey, great to see this realized. One remark (which may be) of minor importance. When you state that:
True semantic objects: things like Names, Adresses, Dates, Times, Geo Coordinates, ... exist only once and are shared among many composites. They are never changed in-place. Updating arbitrary complex composite structures causes no semantic side effects.
I think it would be more correct to say that "... exist only once per workspace" as the same values will inevitably exist more than once, namely in different workspaces / collaborative scenarios / a.k.a SharingModes?.
The reference pool of values already known to the server are different for every users issueing a request to the server. Which, for frontend development would mean, that (the standard case is that a user is working in and member of many workspaces) the same value may exist in more than one workspace. Subsequently the client would still need to send an ID, e.g. a workspace_id so the server can determine which value to use/reference. Which is in contrast to your statement "The client is not required to send IDs or refs. It just sends values." The workspace_id is in any way required right now, so probably nothing will change but I just wanted to have this new way clearly described for frontend developers in advance here. Thanks for your time!
comment:6 Changed 7 years ago by jri
The client is not required to send IDs or refs.
IDs here refers to topic IDs in composite structures.
Thanks for you hint though.
comment:7 Changed 7 years ago by jri
Yes, the same topic can exist more than once, e.g. in private workspaces.
However this does not affect the new data model and update approach described here.
The Core update logic still runs under the request's authority, that is when checking if a certain topic already exists, the Core will not "see" any topic the user has no read permission for.
So, the Core would not share things the user have no permission for. This would make no sense.
Also the workspace approach is not affected by the new data model.
The workspace cookie is still required.
comment:8 Changed 7 years ago by jri
I think this is the way it is supposed to work:
When a user creates e.g. a Person in a private workspace and enter "Berlin" in its address, and a "Berlin" topic exists already in another workspace, where the user has READ permission, that "Berlin" topic will be shared in this case. The Person topic is private, the association to "Berlin" is private, but the "Berlin" topic is shared.
The workspace cookie affects only things being created (as it is now in DM4).
comment:10 Changed 7 years ago by jri
Regarding frontend developer experience:
Lets say a Person with Berlin assigned exists already.
Currently in DM4 if a frontend shows a Person form, and Berlin is not changed by the user when submitting the form, the frontend is supposed to send the ID (ref_id:...) in the update request in order to refer to the existing Berlin topic. Finding out all the IDs puts a big burden on the frontend developer, and also brings the danger of unwanted side effects. When "Berlin" would be just send back as is (as a value instead of a ref ID), the existing "Berlin" topic would be overwritten with e.g. "Munich"! That is the city Berlin is renamed to "Munich"!
Finding out all the ref IDs at client-side is a hard task, in particular when it comes to referring to possibly existing composites like e.g. addresses. (This is why the longstanding problem of "aggregated composites", #337, was never solved in DM4.) Of course the frontend could send several requests just in order to find out if a particular street-postalcode-city-country combination exists already in the DB. But it is much more convenient for the frontend developer if the update logic is located at the server side. Thus all possible frontends -- current and future ones -- will benefit.
With the DM5 approach the frontend just sends the data (just values, no IDs) back to the server as received. This is the best possible frontend developer experience I can think of. And the problem of "aggregated composites" is eventually solved once and for all.
comment:11 Changed 7 years ago by Jörg Richter <jri@…>
comment:12 Changed 7 years ago by jri
I have a question: are you thinking more Identity types do exist, or more Value types? I would like make this the default then.
comment:13 Changed 7 years ago by Jörg Richter <jri@…>
comment:14 Changed 7 years ago by Jörg Richter <jri@…>
comment:15 Changed 7 years ago by Jörg Richter <jri@…>
comment:16 Changed 7 years ago by Jörg Richter <jri@…>
comment:17 Changed 7 years ago by Jörg Richter <jri@…>
comment:18 Changed 7 years ago by Jörg Richter <jri@…>
comment:19 Changed 7 years ago by Jörg Richter <jri@…>
comment:20 Changed 7 years ago by Jörg Richter <jri@…>
comment:21 Changed 7 years ago by Jörg Richter <jri@…>
comment:22 Changed 7 years ago by Jörg Richter <jri@…>
comment:23 Changed 7 years ago by Jörg Richter <jri@…>
comment:24 Changed 7 years ago by Jörg Richter <jri@…>
comment:25 Changed 7 years ago by Jörg Richter <jri@…>
comment:26 Changed 7 years ago by Jörg Richter <jri@…>
comment:27 Changed 7 years ago by Jörg Richter <jri@…>
comment:28 Changed 7 years ago by Jörg Richter <jri@…>
comment:29 Changed 7 years ago by Jörg Richter <jri@…>
comment:30 Changed 7 years ago by Jörg Richter <jri@…>
comment:31 Changed 7 years ago by Jörg Richter <jri@…>
comment:32 Changed 7 years ago by Jörg Richter <jri@…>
comment:33 Changed 7 years ago by Jörg Richter <jri@…>
comment:34 Changed 7 years ago by Jörg Richter <jri@…>
comment:35 Changed 7 years ago by Jörg Richter <jri@…>
comment:36 Changed 7 years ago by Jörg Richter <jri@…>
comment:37 Changed 7 years ago by Jörg Richter <jri@…>
comment:38 Changed 7 years ago by Jörg Richter <jri@…>
comment:39 Changed 7 years ago by Jörg Richter <jri@…>
comment:40 Changed 7 years ago by Jörg Richter <jri@…>
comment:41 Changed 6 years ago by jri
- Status changed from new to closed
- Resolution set to fixed
Identity-Value data model basically done, in master (DM5)
In d7acf9a57df597ed47de5643417610bdf1d5c266/deepamehta: