Implement property_type type field for property value #53

New issue

Closed

opened 2025-05-21 13:59:18 +02:00 by moritz · 2 comments

moritz commented

2025-05-21 13:59:18 +02:00

Owner

No description provided.

moritz added this to the Ich kann einen neuen Kontakt anlegen. milestone 2025-05-21 13:59:18 +02:00

moritz added this to the Sprint 2 - 07.05. - 28.05 project 2025-05-21 13:59:19 +02:00

moritz changed title from ~~Implement property_type type filed for property value~~ to Implement property_type type field for property value

2025-05-21 15:07:42 +02:00

moritz commented

2025-05-21 15:58:56 +02:00

Author

Owner

https://www.dolthub.com/blog/2024-06-25-polymorphic-associations/

Approach to try:
https://hexdocs.pm/ash/polymorphic-relationships.html
https://hexdocs.pm/ash/Ash.Type.Union.html
https://hexdocs.pm/ash_phoenix/union-forms.html

Other approach https://hexdocs.pm/ash_postgres/polymorphic-resources.html

https://www.dolthub.com/blog/2024-06-25-polymorphic-associations/ Approach to try: https://hexdocs.pm/ash/polymorphic-relationships.html https://hexdocs.pm/ash/Ash.Type.Union.html https://hexdocs.pm/ash_phoenix/union-forms.html Other approach https://hexdocs.pm/ash_postgres/polymorphic-resources.html

moritz commented

2025-05-21 16:36:28 +02:00

Author

Owner

Kriterium	🔢 Felder-Methode	🧬 `Ash.Type.Union`	🔄 `polymorphic-relationships`
Speicherung	Mehrere Spalten in einer Tabelle	Ein `:union`-Feld als JSON	Mehrere Beziehungen zu verschiedenen Ressourcen
Typenmodellierung	Statisch durch Spalten	Embedded Ressourcen mit getaggtem Typ	Mehrere `has_one` + `calculation` zur Auswahl
Validierung	Manuell oder über `changeset`	Automatisch je Embedded Resource	Je Ressource separat, zentral via `calculation` kombinierbar
Filterbarkeit (Ash-DSL)	✅ Sehr gut (direkt über Spalten)	❌ Eingeschränkt (nur auf ganzes Union-Feld)	🟡 Mittel (über einzelne Beziehungen, nicht generisch)
Erweiterbarkeit (neue Typen)	🟡 Migration + Code-Anpassung nötig	✅ Nur neue Embedded Resource + Union-DSL	🟡 Neue Beziehung + Anpassung der `calculation` nötig
Speicherformat DB	Klare SQL-Typen (z. B. `date`, `string`, `int`)	JSONB (`value` als Objekt mit `type`-Tag)	Normale relational strukturierte Tabellen
Referentielle Integrität	✅ Ja	❌ Nein (nur JSON)	✅ Ja (echte `has_one` Beziehungen möglich)
Komplexe Datenstrukturen	❌ Schwierig	✅ Sehr gut (verschachtelte Werte, Einheiten, etc.)	✅ Möglich (je nach Zielressource)
Query-Komfort in Ash	✅ Hoch	❌ Eingeschränkt	🟡 Mittel (via `load`/`calculation`)
Performance	✅ Sehr gut	🟡 Mittel (JSON overhead)	🟡 Kommt auf die Umsetzung an (Joins nötig)
Eignung für dynamisch viele Typen	❌ Mühsam	✅ Sehr gut	🟡 Mit Aufwand

Anforderung	Bester Ansatz
Schnelle Filterbarkeit in Queries	🔢 Felder-Methode
Typsichere komplexe Values	🧬 `Ash.Type.Union`
Relationale Datenmodellierung	🔄 `polymorphic-relationships`
Geringer Code-Wartungsaufwand	🧬 `Ash.Type.Union`
Beste Performance bei großen Datenmengen	🔢 Felder-Methode
Komplexe Logik je Typ	🔄 oder 🧬 je nach Validierungstiefe

| Kriterium | 🔢 Felder-Methode | 🧬 `Ash.Type.Union` | 🔄 `polymorphic-relationships` | | ------------------------------------- | ----------------------------------------------- | -------------------------------------------------- | ------------------------------------------------------------ | | **Speicherung** | Mehrere Spalten in einer Tabelle | Ein `:union`-Feld als JSON | Mehrere Beziehungen zu verschiedenen Ressourcen | | **Typenmodellierung** | Statisch durch Spalten | Embedded Ressourcen mit getaggtem Typ | Mehrere `has_one` + `calculation` zur Auswahl | | **Validierung** | Manuell oder über `changeset` | Automatisch je Embedded Resource | Je Ressource separat, zentral via `calculation` kombinierbar | | **Filterbarkeit (Ash-DSL)** | ✅ Sehr gut (direkt über Spalten) | ❌ Eingeschränkt (nur auf ganzes Union-Feld) | 🟡 Mittel (über einzelne Beziehungen, nicht generisch) | | **Erweiterbarkeit (neue Typen)** | 🟡 Migration + Code-Anpassung nötig | ✅ Nur neue Embedded Resource + Union-DSL | 🟡 Neue Beziehung + Anpassung der `calculation` nötig | | **Speicherformat DB** | Klare SQL-Typen (z. B. `date`, `string`, `int`) | JSONB (`value` als Objekt mit `type`-Tag) | Normale relational strukturierte Tabellen | | **Referentielle Integrität** | ✅ Ja | ❌ Nein (nur JSON) | ✅ Ja (echte `has_one` Beziehungen möglich) | | **Komplexe Datenstrukturen** | ❌ Schwierig | ✅ Sehr gut (verschachtelte Werte, Einheiten, etc.) | ✅ Möglich (je nach Zielressource) | | **Query-Komfort in Ash** | ✅ Hoch | ❌ Eingeschränkt | 🟡 Mittel (via `load`/`calculation`) | | **Performance** | ✅ Sehr gut | 🟡 Mittel (JSON overhead) | 🟡 Kommt auf die Umsetzung an (Joins nötig) | | **Eignung für dynamisch viele Typen** | ❌ Mühsam | ✅ Sehr gut | 🟡 Mit Aufwand | | Anforderung | Bester Ansatz | | -------------------------------------------- | ------------------------------------ | | **Schnelle Filterbarkeit in Queries** | 🔢 Felder-Methode | | **Typsichere komplexe Values** | 🧬 `Ash.Type.Union` | | **Relationale Datenmodellierung** | 🔄 `polymorphic-relationships` | | **Geringer Code-Wartungsaufwand** | 🧬 `Ash.Type.Union` | | **Beste Performance bei großen Datenmengen** | 🔢 Felder-Methode | | **Komplexe Logik je Typ** | 🔄 oder 🧬 je nach Validierungstiefe |

moritz referenced this issue from a pull request that will close it,

2025-05-22 02:02:25 +02:00

property values as maps closes #53 #56

moritz self-assigned this 2025-05-22 02:13:35 +02:00

moritz modified the project from Sprint 2 - 07.05. - 28.05 to Sprint 3 - 28.05 - 09.07

2025-05-28 16:50:52 +02:00

moritz closed this issue

2025-05-29 15:34:25 +02:00

moritz referenced this issue from a commit

2025-05-29 15:34:26 +02:00

Merge pull request 'property values as maps closes #53' (#56) from property_values into main