SHeinrich
Returning Observer

Entity.setState oder erzwingen eines commit()

Jump to solution

Hallo Community!

Wir greifen über die fs-access API auf content2-Entitys zu und ändern diese. In den Fällen wo wir nur Listen (Beziehungen) ändern und der Rest unverändert bleibt, hat das Entity weiterhin den Status PersistentState.CHANGING. Ein manuelles ändern  per setState() o.ä. ist nicht vorgesehen.

Als Workaround ändern wir nun das erste änderbare Attribnut im Entity, führen ein commit() durch und setzen den alten Wert erneut um die Änderungen persistent abzuspeichern. Gibt es schönere Möglichkeiten? Spätestens wenn man kein Feld außer Listen hat wird dies nicht funktionieren.

Danke!

0 Kudos
1 Solution

Accepted Solutions

Hallo Sergej,

danke für deine Beschreibung. Das Szenario ist nachvollziehbar, allerdings ist das glaube ich ein Bereich, wo wir nicht viel Unterstützung geben können, weil sich das alles so ein bisschen abseits der normalen Praktiken bewegt.

meine Erwartungshaltung wäre hier auch gewesen, dass das Ändern der Beziehungen als Änderung gezählt wird, allerdings kann ich hierzu keine offizielle Information finden. Ich würd dich bitten das einfach mal als Bug bei uns zu melden, dann bekommst du auf jeden Fall eine umfassende Antwort dazu. Auch das mit dem FS_INDEX ist etwas, wo man erwarten könnte, dass es funktioniert - ich denke aber, dass das ohne Weiteres nicht möglich ist und dass es vielleicht noch andere Möglichkeiten gibt die Referenzänderungen zu propagieren. Auch hier würde ich dich bitten einen separaten Bug einzustellen, das ist am effizientesten.

Danke und Grüße,

Hannes

View solution in original post

0 Kudos
3 Replies
mikula
Crownpeak employee

Hallo Sergej,

Datenbank-manipulationen sind generell gefährliches Terrain. Ich nehme einfach mal an, dass Ihr Skripte laufen lasst, die dann für euch entsprechende Manipulationen durchführen. Ich kann dir leider keinen Workaround nennen, aber mich interessiert wirklich brennend der use-case. Sprich: warum ihr welche Datenbank-Interaktion durchführen müsst. Vielleicht kann man auf diese weise einen anderen Workaround finden?

Viele Grüße

Martin

0 Kudos
SHeinrich
Returning Observer

Hallo,

gerne nenne ich nen Use-Case in der Hoffnung auf Tipps zur Verbesserung.

Wir haben eine komplexere Telefonbuch-Anwendung mit Daten auf dem SQL-Server. Die "lesende" Einbindung dieser Daten hat nicht geklappt (GID nicht als Primärschlüssel erkannt, fremde n:m Beziehungen nicht über FirstSpirit gescheit darstellbar). Nun erfolgt ein Datenimport über die fs-access-API mit entsprechender Transformierung der Daten, damit die Daten in FirstSpirit ordentlich nutzbar sind. Neben dem Import der gut funktioniert ist auch ein Update in Mache. Und genau bei diesem Schritt stoßen wir auf das o.g. Problem.

Heute haben wir ein weiteres Problem feststellt mit FS_INDEX. Die Listeneinträge werden nach Update gespeichert aber nicht im FirstSpirit Datenquelle-Formular angezeigt, jedoch in der Versionshistorie. Bug? Aber das geht vermutlich am Thema vorbei. Wir melden es seperat falls Ihnen die Problemetik jetzt neu ist.

Ist der Use-Case und die damit entstehenden Probleme halbwegs verständlich?

Gruß,

0 Kudos

Hallo Sergej,

danke für deine Beschreibung. Das Szenario ist nachvollziehbar, allerdings ist das glaube ich ein Bereich, wo wir nicht viel Unterstützung geben können, weil sich das alles so ein bisschen abseits der normalen Praktiken bewegt.

meine Erwartungshaltung wäre hier auch gewesen, dass das Ändern der Beziehungen als Änderung gezählt wird, allerdings kann ich hierzu keine offizielle Information finden. Ich würd dich bitten das einfach mal als Bug bei uns zu melden, dann bekommst du auf jeden Fall eine umfassende Antwort dazu. Auch das mit dem FS_INDEX ist etwas, wo man erwarten könnte, dass es funktioniert - ich denke aber, dass das ohne Weiteres nicht möglich ist und dass es vielleicht noch andere Möglichkeiten gibt die Referenzänderungen zu propagieren. Auch hier würde ich dich bitten einen separaten Bug einzustellen, das ist am effizientesten.

Danke und Grüße,

Hannes

0 Kudos