Von acts_as_tree, acts_as_nested_set migrieren

Community DE
1

ja hallo erstmal,…

ich stehe hier vor einem kleinen Problem:
Wir haben eine kleine Materialverwaltung. Material ist in Gruppen
aufgeteilt:
Beispiel:
Ein Schraubendreher ist Teil des Satzes “Schraubendreher Paket”, dies
ist Teil
des Satzes Werkzeugkasten, dies ist Teil des Satzes Fahrzeug.

(Streng genommen ist der Schraubendreher auch wiederrum ein Satz, für den
Einzelne Bits hinterlegt werden können).

Dabei können z.B. diese Use-Cases auftreten:
a) Der Werkzeugkasten wird vom Fahrzeug genommen und eingelagert.
b) Das Schraubendreher Set ist nicht mehr Teil eines Werkzeugkasten,
sondern
wird direkt in der Werkstatt an die Wand gehangen.
c) Zu einem Satz (oder Teil) liegt ein Defekt vor, der erfasst werden
muss.

Bislang wird die Ansicht via “acts_as_tree” gerendert. dies ist jedoch
ungeschickt, da häufig der ganze Baum geladen werden muss. -> n viele
SQL-Queries.
Ich überlege gerade, das ganze in ein nested-Set zu überführen. Was haltet ihr
davon?

An ein paar Dingen hakt es derzeit:

-e s scheint eine Erweiterung acts_as_thread zu geben, dessen Homepage
ich
nicht erreiche und die besser geeignet sein könnte - stimmt dies?

  • Ich bin leider was DB-Performance anbelagt nicht so bewandert:
    Wie schlagen sich die Oben beschriebenen Use-Cases im Vergleich zu einem
    vollen Auslesen des Baums? Macht es Sinn auf acts_as_nested_set zu
    migrieren?

  • Kann ich a_a_n_s genauso verwenden wie a_a_t? D.h. parent_id setzen
    und gut
    ist’s, oder muss ich mich in einem der o.g. UC-Cases noch um left,
    right,
    etc. kümmern.
    Im Use-Case b) würde sich sogar der Scope ändern - da nun der
    Schraubendrehersatz nicht mehr Mitglied der Listen Werkzeugkasten,
    Fahrzeug
    ist. Kann Rails das automatisch?
    Ich stelle es mir ein wenig haarig vor, Scopes manuell zu führen, da jeder
    Knoten im Baum eine Wurzel eines potentiellen Baums ist und bei einem
    Zerlegen der Baumstruktur neue Scopes gesetzt werden müssten … oder kann
    Rails das automatisch?

  • Im Fall einer Migration müsste ich die vorhandene DB-Struktur in das neue
    Format migrieren. Das hinzufügen der Spalten wird natürlich kein Problem
    sein - gibt es aber einen einfach Weg, die neuen Attributes (lft, fgt,
    root,
    scope) zu setzen, oder ist hier SQL-Handarbeit gefragt?

So, das war’s dann aber auch…

Alles Gute
Jan

2

Hallo!

Wenn Dein Baum groß genug ist macht die Nutzung des Nested
Set Algorithmus immer Sinn. Achte drauf, daß Du “better nested
set” nutzt, eine Ãœberarbeitung / Erweiterung, die ein paar
Probleme beseitigt und zusätzliche Funktionalität wie die
Behandlung von Teilbäumen unterstützt.

Ein Schraubendreher ist Teil des Satzes “Schraubendreher Paket”,
dies ist Teil des Satzes Werkzeugkasten, dies ist Teil des
Satzes Fahrzeug.

Baum, mehrere Bäume? Du kanst mehrere Bäume im selben Modell /
Tabelle halten, wenn Du den scope Parameter nutzt, um die
einzelnen Bäume zu unterscheiden.

Dabei können z.B. diese Use-Cases auftreten:
a) Der Werkzeugkasten wird vom Fahrzeug genommen und eingelagert.

Teilbaum um- / aushängen? Sollte mit better nested set gehen. Bitte
nochmal Doku checken.

b) Das Schraubendreher Set ist nicht mehr Teil eines Werkzeugkasten,
sondern wird direkt in der Werkstatt an die Wand gehangen.

s.o.

c) Zu einem Satz (oder Teil) liegt ein Defekt vor, der erfasst werden muss.

has_many :defects?

Ich überlege gerade, das ganze in ein nested-Set zu überführen.
Was haltet ihr davon?

Hängt von der Größe und vor allem Tiefe ab.

  • Kann ich a_a_n_s genauso verwenden wie a_a_t? D.h. parent_id setzen
    und gut ist’s, oder muss ich mich in einem der o.g. UC-Cases noch um
    left, right, etc. kümmern.

Node erzeugen und einhängen. Ggf. scope setzen. Mehr ist nicht. Mit
left und right hast Du nichts zu tun.

Im Use-Case b) würde sich sogar der Scope ändern - da nun der
Schraubendrehersatz nicht mehr Mitglied der Listen Werkzeugkasten,
Fahrzeug ist. Kann Rails das automatisch?

Ah. Hätte ich mal vorher komplett lesen sollen: Better nested set sollte
das können.

Ich stelle es mir ein wenig haarig vor, Scopes manuell zu führen,
da jeder Knoten im Baum eine Wurzel eines potentiellen Baums ist
und bei einem Zerlegen der Baumstruktur neue Scopes gesetzt werden
müssten … oder kann Rails das automatisch?

Wenn Du auf scopes verzichten müstest könntest Du ja alles in einem
Baum (mit einem Root Element) halten.

  • Im Fall einer Migration müsste ich die vorhandene DB-Struktur
    in das neue Format migrieren. Das hinzufügen der Spalten wird
    natürlich kein Problem sein - gibt es aber einen einfach Weg, die
    neuen Attributes (lft, fgt, root, scope) zu setzen, oder ist hier
    SQL-Handarbeit gefragt?

Nochmal, bis auf parent und ggf. scope läuft alles automatisch.
Eine Migration sollte problemlos sein, wenn Du weißt, wie
Du Deinen Originalbaum traversieren mußt.

Ich habe mal kurz mit acts as tree und better nested set rumgespielt.
Mit der Teilbaumfunktionalität (löschen, verschieben, etc.) bin ich
mir zwar nicht 100% sicher, aber ich denke das war die Hauptmotivation
für die Überarbeitung.

Kann sein, daß ich Deine Fragen falsch interpretiert habe, kannst
gern nochmal korrigieren / nachfragen. Am besten Du spielst einfach
mal damit in der console rum. Mehr als 30 Minuten, max. eine Stunde
sollte Dich das nicht kosten.

Gruß! - Bernd