Erfahrungen mit Workarounds für gemischte Keys

Hallo Zusammen,

in AL besteht ja das Problem, dass man in Tableextensions nur Keys anlegen kann mit Feldern aus der Tableextension selbst.
Man hat also keine Möglichkeit Felder der Originaltabelle in einem neuen Key der Tableextension zu verwenden, z.B. kann man in einem neuen Key einer Tableextension, welche die Tabelle Item erweitert keine Felder aus Item nutzen (z.B.: 10 Art, 16 Statisikgruppe, 31 Kreditorennr, ...).
Dieses Problem wird auch hier skizziert und diskutiert: https://github.com/microsoft/AL/issues/1054

Zwar ist in der OnPremise-Variante derzeit theoretisch noch die Erweiterung der Standard-Originaltabelle (z.B.: 27 Item) möglich, aber dies ist für die Zukunft ja bereits abgekündigt.

Mich würde nun sehr interessieren welche Erfahrungen mit Workarounds für dieses Problem gemacht wurden, insbesondere auch mit den folgenden 2 Workarounds:

- 1. Workaround: Schattenfelder

• benötigte Felder der Originaltabelle als Schattenfelder anlegen und über Insert/Modify/Rename-Subscriber dafür sorgen, dass diese synchron zu den Originalfeldern gehalten werden.
  In diesem Fall können gemischte Keys in der Tableextension über die Schattenfelder ja wieder angelegt werden.
  
• Vorteil: Es müssen nur in den genutzten Key-Aufrufen die Originalfelder mit den Schattenfeldern ausgetauscht werden und es ist kein weiterer Codeumbau nötig.
  
• Nachteil: Die Daten der Schattenfelder werden natürlich zum 2en Mal gespeichert, verbrauchen also zusätzlichen Speicherplatz. Zudem ist für die Pflege der Schattenfelder ja ein Zusatzaufwand nötig.
• Im folgenden Post scheint es so, als ob sich auch Microsoft überlegt dies in generellerer Form technisch zur Verfügung zu stellen über "platform-managed field mirroring for fields needed in new indexes"
  https://github.com/microsoft/AL/issues/730#issuecomment-337013729

- 2. Workaround: Queries

• Nutzung von Queries anstatt Keys
  
• Dieser Workaround ist z.B. hier skizziert: https://www.adv-usa.com/post/business-central-workaround-cross-keys-al-table-extension
  
• Frage ist hier sicher auch, wie performant solche Query-Konstukte gegenüber dem passenden Key wirklich sind.
  
• Nachteil: Hier sind ggf. alle Codestellen, in denen der gewünschte Key genutzt wird umzubauen, auch Flowfields, die auf dem gewünschten Key aufbauen.
  Dies setzt natürlich auch voraus, dass man an die umzubauenden Codestellen überhaupt drankommt ( über passende Event-Subscriber).

Bin für alle Einschätzungen / Ideen / Erfahrungen hierzu dankbar !

Blue

Hallo,

Die Schattenfelder benötigen in jedem Fall zusätzlichen Aufwand, egal ob von der Plattform bereitgestellt oder selbst programmiert. Außerdem benötigen zusätzliche Schlüssel einen erhöhten Zeitaufwand beim Schreiben, mal ganz davon abgesehen, das du Standard- FlowFields damit nicht erweitern kannst.
Das mit dem austauschen der Felder nur wo du Sie brauchst ist meist nicht wirklich möglich. Wir haben z.B. ein Feld "Verbandsnr." und den Kreditorenposten (und in den entsprechenden FlowFields). Alle betreffenden Standard- FlowFields im Kreditor sind entsprechend erweitert, um auf die Verbwandsnr. filtern zu können. Das würde für uns bedeuten, alle Zugriffe auf diese Felder zu ersetzten (Bewegung, Verkauf (MW),....) Ich denke, das wird im Zeitalter der Extensions kaum möglich sein.

Für Queries gilt übrigens genau das gleiche.

Generell wird immer wieder vergessen, das auch andere Apps in einer Lösung installiert sein können, die die Standardfelder und -Funktionen benötigen. Du kannst also nicht einfach ein Feld kopieren und das alte ausblenden oder eine Funktionalität per "Handled"- Parameter überspringen.

Gruß Fiddi

[Kowa]

--> Herzlichen Dank für Deine Hinweise / Einschätzungen , Fiddi !

Zuletzt geändert von Kowa am 15. Juni 2020 17:26, insgesamt 1-mal geändert.
Grund: Vollzitat entfernt