joachim_nissler
Returning Observer

1:N Relation und FS_INDEX

Jump to solution

Folgendes Szenario:

Einem Job-Image seien immer mehrere BusinessUnits zugeordnet.

000061.jpg

Die BusinessUnits möchte ich gerne anhand eines FS_INDEX pflegen.
000062.jpg
Entsprechend mache ich das Mapping
000063.jpg
Möchte ich das ganze jetzt im Formular des JobImages Speichern bekomme ich eine Exception:
java.lang.IllegalArgumentException: tt_business_unitList is no list attribute
at de.espirit.or.impl.EntityImpl.getList(EntityImpl.java:173)
at de.espirit.firstspirit.store.access.contentstore.ContentUtil.setRelations(ContentUtil.java:419)
at de.espirit.firstspirit.store.access.contentstore.ContentUtil.storeDataValue(ContentUtil.java:374)
at de.espirit.firstspirit.store.access.contentstore.ContentUtil.storeData(ContentUtil.java:330)
at de.espirit.firstspirit.store.access.contentstore.ContentUtil.storeData(ContentUtil.java:321)
at de.espirit.firstspirit.store.access.contentstore.ContentUtil.nStoreData(ContentUtil.java:307)
at de.espirit.firstspirit.store.access.contentstore.DatasetImpl.setData(DatasetImpl.java:464)
at de.espirit.firstspirit.store.access.DataUtil.injectFormData(DataUtil.java:65)
at de.espirit.firstspirit.ui.views.controls.IDProviderControls$1.storeFormData(IDProviderControls.java:130)
.
.
.
Was genau mach ich falsch? Und wo in der Doku wäre zu finden, wie es richtig geht?
0 Kudos
1 Solution

Accepted Solutions
hoebbel
Crownpeak employee

Hallo Joachim,

ich sehe auf Anhieb den Fehler auch nicht. Mich macht aber erst einmal misstrauisch, dass es eine gerichtete Fremdschlüsselbeziehung ist (im Ziel kein Fremdschlüssel). Gibt es dafür einen Grund? Wenn nicht, würde ich die Fremdschlüsselbeziehung neu anlegen und in beide Richtungen zulassen. Dann spart man sich auch Folgeprobleme, wenn in Zukunft doch mal die andere Richtung benötigt wird.

Anhand der zur Verfügung gestellten Informationen kann ich zwar vermuten, dass tt_business_unit_list die zuN Richtung der Fremdschlüsselbeziehung abdeckt - das kann aber auch die zu1 Richtung sein.

Das Ganze könnte auch ein Timing Problem sein und sich durch Neustart des entsprechenden Clients von alleine behoben haben...

Vielleicht helfen diese Gedanken ja weiter, wenn das Problem noch bestehen sollte.

Viele Grüße
Holger

View solution in original post

2 Replies
hoebbel
Crownpeak employee

Hallo Joachim,

ich sehe auf Anhieb den Fehler auch nicht. Mich macht aber erst einmal misstrauisch, dass es eine gerichtete Fremdschlüsselbeziehung ist (im Ziel kein Fremdschlüssel). Gibt es dafür einen Grund? Wenn nicht, würde ich die Fremdschlüsselbeziehung neu anlegen und in beide Richtungen zulassen. Dann spart man sich auch Folgeprobleme, wenn in Zukunft doch mal die andere Richtung benötigt wird.

Anhand der zur Verfügung gestellten Informationen kann ich zwar vermuten, dass tt_business_unit_list die zuN Richtung der Fremdschlüsselbeziehung abdeckt - das kann aber auch die zu1 Richtung sein.

Das Ganze könnte auch ein Timing Problem sein und sich durch Neustart des entsprechenden Clients von alleine behoben haben...

Vielleicht helfen diese Gedanken ja weiter, wenn das Problem noch bestehen sollte.

Viele Grüße
Holger

Die Richtungen der Relation haben schon gepasst. Und sind auch absichtlich nur als 1:N gewählt worden.

Der springende Punkt war offenbar der Neustart des Clients.

Unverändert läuft es jetzt wie es soll 🙂

Besten Dank, @hoebbel!

0 Kudos