Scripting-Frage
Author: rbitdd
Publication Date: 5/29/2012 13:26
Hallo Community,
für gewöhnlich schreibe ich nur "normale" Templates, sehe aber für die bestehende Anforderung keine Möglichkeit die Aufgabe ohne Scripting zu lösen...
Aufgabe ist wie folgt:
_____________________________________________________________________________________________________
Aus einem bestimmten Bestand an Bildern sollen Keyvisuals wöchtenlich ausgetauscht werden. Diese Keyvisuals müssen alle einmal verwendet werden, bevor sich eines wiederholen darf. Eine bestimmte Reihenfolge ist irrelevant.
Ich dachte dabei die Bilder in eine Datenquelle zu legen und mit Flags zu arbeiten.
D.h. ich mache ein ContentSelect auf die Datenquelle, nehme mir das erste Element aus der Liste, markiere dieses als "current" und lese bei der Verwendung des KV das Bild mit dem Flag "current" aus.
Beim nächsten Durchlauf wird bei dem Bild mit dem Flag "current" das Flag "current" entfernt und ein Flag "used" gesetzt und ein neues Bild ausgewählt und entsprechend markiert.
Ein Kollege meinte, ich solle mir vom Redakteur die Reihenfolge definieren lassen und damit arbeiten. Dies hätte den Vorteil, dass ich die DQ nicht manipulieren muss, in meinen Augen jedoch den Nachteil, das ich mir den "aktuellen Status" irgendwie merken muss... Da mir kein "einfacher Weg" einfällt, wie ich mir das merken kann, fällt die Option für mich ganz aus...
Mir fällt gerade ein, ich muss sicherlich noch darauf achten, dass die geänderten Datensätze freigegeben werden...
_____________________________________________________________________________________________________
So, jetzt mein Anliegen:
- Ich hab keine Ahnung, ob meine geplante Vorgehensweise überhaupt geeignet ist.
- Ich hab keine Ahnung, wie ich ansetzen soll.
- Ich hab überhaupt keine Ahnung vom Scripting, würde diesen Umstand jedoch gerne ändern...
D.h. mir wäre vermutlich lerntechnisch am meisten damit geholfen, wenn mich jemand "in die richtige Richtung schubsen würde". Ich nehme jedoch auch gerne Lösungsvorschläge entgegen, welche ich nur noch anpassen muss und vielleicht daran dann etwas lerne. :smileywink:
Freue mich auf hilfreiche Antworten.
Viele Grüße
Tags: datenquellen, deployment, scripting
-
Author: Peter_Jodeleit - 5/29/2012 13:41
Ich schubse ja eigentlich sonst niemanden...
Man kann Werte über die verschiedenen Ausführungen eines Auftrages hinweg retten:
$CMS_SET(_void, #global.scheduleContext.setVariable("index_keyvisual", index))$
Reicht das als Hinweis? Die Lösung würde damit sogar ohne "Scripting" auskommen :smileywink:
0 -
Author: rbitdd - 6/5/2012 20:48
Hallo,
- danke für die Antwort.
- so richtig hilft mir das nicht weiter. Wenn ich die Variable in den ScheduleContext schreibe, habe ich diese doch nur in meinem Auftrag zur Verfügung. D.h. wenn ich mir einmal wöchentlich einen Auftrag ausführen lasse, der die Logik des Wechsels übernimmt, habe ich den aktuellen Wert doch nur in diesem Auftrag zur Verfügung stehen und nicht in dem der eigentlichen Veröffentlichung durchführt, oder?
Wenn ich die Logik in die Veröffentlichung schreibe, erfolgt der Wechsel zu häufig, oder ich habe gar nicht erst den aktuellen Wert zur Verfügung.
Ich freue mich auf weitere "sachdienliche Hinweise" :smileywink:
0 -
Author: Peter_Jodeleit - 6/6/2012 7:08
Wenn ich die Variable in den ScheduleContext schreibe, habe ich diese doch nur in meinem Auftrag zur Verfügung.
Hast du dir die API-Doc der Methode durchgelesen? Da steht etwas anderes..
Und ich schrieb doch auch: "Man kann Werte über die verschiedenen Ausführungen eines Auftrages hinweg retten".
0 -
Author: rbitdd - 6/6/2012 7:56
Also, ich hab in die Doc geguckt.
A context with access to schedule entry execution-related objects.
Klingt für mich jetzt eher so, als würde die Variable zwar durchaus über die Ausführung EINES Auftrages hinaus retten, aber immer noch nicht, dass sie im Kontext eines anderen Auftrages ebenfalls zur Verfügung steht. Daher habe ich mir die Beschreibung der Methode gar nicht erst weiter angeguckt.
Und selbst bei näherer Betrachtung der Methode würde ich nicht wagen anzunehmen, das mir das weiterhilft.
Sets a variable to this context. This variable will be hold persistent beyond the schedule execution.
Use
ScheduleContext.setProperty(String, Object)to set a property only for the time of the schedule execution.Da steht für mich ganz klar "dieser Kontext", was für mich in dem Fall eineindeutig bedeutet, dass der Kontext dieser Auftrag ist und nicht alle anderen Aufträge auch.
Daraus folgend bedeutet das für mich, das ich bei durchführung dieses Auftrags sehr wohl immer noch weiß, welcher Wert bei der letzten Durchführung gesetzt war und somit mir auch bei der nächsten Durchführung noch zur Verfügung steht.
Zusammenfassend und in kurz beschrieben, was ich benötige:
Ich brauche ein Skript, welches mir in einem festen Turnus (wöchentlich) einen Wert setzt, welcher bis zur nächsten Durchführung des Skriptes in allen anderen Aufträgen gültig ist.
0 -
Author: Peter_Jodeleit - 6/6/2012 13:06
Wieviele verschiedene Aufträge sind das denn?
0 -
Author: rbitdd - 6/6/2012 13:17
Wir befinden uns zur Zeit noch in der Entwicklungsphase. Zur Zeit sind ca. 10 verschiedene Aufträge definiert. Ich denke, sobald das Projekt in die Fachbereiche geht, werden hier jedoch noch ein Paar hinzukommen...
0 -
Author: Peter_Jodeleit - 6/6/2012 13:36
Ich war von einem Auftrag ausgegangen.
Dann würde ich einfach eine Liste der "Visuals" erstellen und dann jeweils das an Index "aktuelle Kalenderwoche minus eins modulo Anzahl der Visuals" nehmen.
Pseudocode:
$CMS_VALUE(visual_list[(#global.startDate.week_of_year - 1) % visual_list.size])$
Die Liste der Visuals kann man z.B. per Content-Select aus einer Datenquelle erstellen.
[Anmerkung: "week_of_year" fängt bei 1 an zu zählen]
0 -
Author: rbitdd - 6/6/2012 14:03
Ja, aber das funktioniert am besten, wenn die Anzahl der Visuals der Anzahl der KWs entspricht, oder kleiner ist. Wir haben aber jetzt schon um die 60 und es werden eher mehr.
Hinzukommt, dass eine Änderung der Liste durch Löschen von Elementen, dazu führt, dass Elemente übersprungen werden, bevor wir an das Ende der Liste kommen und die Wiederholung anfängt.
Und zum Verständnis: der Code müsste dann bei jedem Deployment ausgeführt werden, oder?!?
0 -
Author: Peter_Jodeleit - 6/6/2012 14:25
Mein allerletzter Vorschlag: An den Visuals wird ein Gültigkeitszeitraum definiert.
0 -
Author: rbitdd - 6/6/2012 14:49
Mein allerletzter Vorschlag: An den Visuals wird ein Gültigkeitszeitraum definiert.
Schade, aber das ist leider auch für diese Aufgabe nicht praktikabel, da der Redakteur dann mehr oder minder gezwungen wäre mind. einmal im Jahr alle Visuals zu bearbeiten... Das ist nicht gewünscht... :smileysad:
0 -
Author: broszeit - 6/11/2012 10:37
Hallo,
verstehe ich das richtig, dass die 10 unterschiedlichen Aufträge jeweils auf unterschiedliche Bilder aus dem Pool zugreifen sollen und alle aufpassen sollen, dass sie "unbenutzte" Bilder wählen?
Oder sollen die Bilder von einem Auftrag für die Woche einmalig ausgewählt werden und die 10 anderen Aufträge nutzen dann alle dieselben ausgewählten Bilder?
Viele Grüße
Rouven
0 -
Author: rbitdd - 6/11/2012 11:21
Also, es gibt ca. 10 Aufträge, welche innerhalb einer Woche alle DAS SELBE Bild verwenden sollen.
Es kann gerne ein wöchentlicher Auftrag erzeugt werden, welcher für die "Verwaltung" des KVs zuständig ist.
Also im Prinzip:
Oder sollen die Bilder von einem Auftrag für die Woche einmalig ausgewählt werden und die 10 anderen Aufträge nutzen dann alle dieselben ausgewählten Bilder?
Viele Grüße
0 -
Author: broszeit - 6/11/2012 12:57
Dann müsste es möglich sein, den Weg aus dem Ursprungspost zu gehen die Flags in der Datenquelle zu speichern. Die anderen Aufträge holen sich dann einfach den Datensatz auf dem das "current" Flag gesetzt ist.
So als kleines Beispiel, habe ich mal ein paar Schnipsel an Scriptcode zusammengestellt:
Das Holen aller Entities:
private Project p = context.getProject();
// get the master language
Language lang = p.getMasterLanguage();
// get the stores
ContentStoreRoot cs = (ContentStoreRoot) p.getUserService().getStore(Store.Type.CONTENTSTORE, false);
// get pressReleases contentStore element
Content2 contentStore = (Content2) cs.getStoreElement("<tabellenname>", IDProvider.UidType.CONTENTSTORE);
// get database schema and session
Schema schema = contentStore.getSchema();
Session session = schema.getSession();
// get entity from datasource
Select select = session.createSelect(contentStore.getEntityType().getName());
EntityList entityList = session.executeQuery(select);
Durch diese Liste kann dann iteriert werden und geprüft werden ob auf dem jeweiligen Entity aktuell das "current" Flag gesetzt ist. Wenn ja, dann einfach auf "used" setzen. Das erste Entity mit dem "unused" Flag kann man dann z.B. auf current setzen.
Daten setzen und holen geht ungefähr so:
try {
contentStore.lock(entity);
Dataset dataSet = contentStore.getDataset(entity);
FormData data = dataSet.getFormData();
// add text to headline into database
FormField formField = data.get(lang, "cs_flag");
//pruefen ob Bild aktuell verwendet wird
if(formField.get().equals("current")) {
//dann den Status ändern
formField.set("used");
// Speichern und Freigeben
dataSet.setFormData(data);
dataSet.save();
contentStore.release(entity);
}
} catch (Exception ex) {
ex.printStackTrace();
} finally {
contentStore.unlock(entity);
}
Ich hoffe das reicht erstmal als erster "Schubser" für eine grobe Richtung.
Viele Grüße
Rouven
EDIT: "csPressreleases" durch "contentStore" ersetzt
0 -
Author: tklein - 6/11/2012 13:40
Kleine (Performance)Optimierung ;-)
Rouven Broszeit schrieb:
private Project p = context.getProject();
// get the master language
Language lang = p.getMasterLanguage();
// get the stores
ContentStoreRoot cs = (ContentStoreRoot) p.getUserService().getStore(Store.Type.CONTENTSTORE, false);
// get pressReleases contentStore element
Content2 contentStore = (Content2) cs.getStoreElement("<tabellenname>", IDProvider.UidType.CONTENTSTORE);
// get database schema and session
Schema schema = contentStore.getSchema();
Session session = schema.getSession();
// get entity from datasource
Select select = session.createSelect(contentStore.getEntityType().getName());
EntityList entityList = session.executeQuery(select);
Alle Datensätze bkommt man sehr schnell und einfach mit: Content2.getData();
Allerdings kann man besser das Query erweitern als über alle Datesnätze generieren:
// get entity from datasource
Select select = session.createSelect(contentStore.getEntityType().getName());
Equal equal = new Equal("cs_current", true);
select.setConstraint(equal);
EntityList entityList = session.executeQuery(select);
Ähnliches dann für die "unused" Datensätze. und dann ein zufälliges element von der Liste holen. Liefert die liste nichts alle Datensätze wiede auf unused = true setzen
0 -
Author: rbitdd - 6/20/2012 8:59
Hallo zusammen,
ich würde behaupten, ich bin kurz vor dem Ziel.
Wenn man von ein paar Widrigkeiten bzgl. des Setzens von Bedingungen absieht.
Ich bin wieder dazu über gegangen ALLE Datensätze abzufragen, da es Schwierigkeiten gibt mehrere UND-Bedingungen über eine ODER-Bedingung zu verbinden.
Wie dem auch sei...
Wenn ich das mit den Einschränkungen richtig verstanden habe, werden hier die Formularfelder angegeben.
Wie muss denn die Bedingung aussehen, wenn ich nur die Datensätze mit aktuellem Release haben möchte?
ATM versuche ich über entity.isReleased() mir weiterzuhelfen, jedoch funktioniert das nicht besonders gut...
Kann mir jemand weiterhelfen?
Freue mich auf Antworten.
Viele Grüße
0 -
Author: tklein - 6/20/2012 10:04
da die Abfrage immer noch der empfohlene Weg ist, würden mich die Schwirigkeiten interressieren. Der Weg wäre ja sowas:
and1 = new And (...,....);
and2 = new And();
or = new OR();
or.add(and1);
or.add(and2);
und dann das or an das select geben...
Um zwischen released und current Daten zu unterscheiden, muss man sich die release-session holen.
Schema.getSession(boolean release);
Für den schnellen Weg über das Content2 nur die freigegeben Datensätze zu ermitteln gibt es im Moment keinen Weg.
0 -
Author: gockel - 6/20/2012 11:51
Für die Nutzung einer komplexeren Abfrage innerhalb der API, würde ich immer empfehlen sich diese im JavaClient (im Templatestore) über den Wizard zusammenzuklicken und diese dann auch zu verwenden. Also:
1) Abfrage "mySpecialQueryUID" unterhalb des entsprechenden Schemas anlegen
2) Einschränkung über den Wizard zusammenklicken -> speichern
3) Innerhalb der API-Benutzung das Select von dieser Abfrage (Query) holen
import de.espirit.firstspirit.access.store.templatestore.Query;
TemplateStoreRoot templateStore = ....
query = templateStore.getStoreElement("mySpecialQueryUID", Query.UID_TYPE);
EntityList entityList = session.executeQuery(query.getSelectStatement());
0 -
Author: rbitdd - 6/20/2012 16:16
Tobias Klein schrieb:
da die Abfrage immer noch der empfohlene Weg ist, würden mich die Schwirigkeiten interressieren. Der Weg wäre ja sowas:
and1 = new And (...,....);
and2 = new And();or = new OR();or.add(and1);or.add(and2);
und dann das or an das select geben...
Ein hoch auf die History:
So etwas hatten wir uns auch schon gedacht. Der Code sah wie folgt aus: (Mir fällt auch jetzt erst auf, wie "blöd" die Bedingung gesetzt ist, aber das wäre mir sicher noch aufgefallen.. :smileywink:)
select_new_current = session.createSelect(contentStore.getEntityType().getName());
equal1 = new Equal("flag_current",false);
equal2 = new Equal("flag_used",false);
and1 = new And(equal1,equal2);
equal3 = new Equal("flag_current",null);
equal4 = new Equal("flag_used",null);
and2 = new And(equal3,equal4);
or = new OR();
or.add(and1);
or.add(and2);
select_new_current.setConstraint(or);
und führte zu dieser Fehlermeldung:
Siehe Dateianhang
Des Weiteren
Um zwischen released und current Daten zu unterscheiden, muss man sich die release-session holen.
Schema.getSession(boolean release);
Für den schnellen Weg über das Content2 nur die freigegeben Datensätze zu ermitteln gibt es im Moment keinen Weg.
Diese Änderung führt leider zu "merkwürdigen Verhalten" meiner DQ. Es tauchen bereits gelöschte Elemente wieder auf, nur weil diese noch das Flag "current" hatten. Wenn diese dann "endgültig" gelöscht sind und das "erst beste Element" welches freigegeben ist, das Flag "current" bekommen soll, bekomme ich folgende (extrem gekürzte) Fehlermeldung
java.lang.UnsupportedOperationException: Release an entity with a release session isn't supported
Es sieht für mich nicht so aus, als könne ich mit einer Session im "Release-Status" Daten freigeben. Die Manipulation an sich hat funktioniert...
Also auch hier: Schade. :smileysad:
0 -
Author: tklein - 6/20/2012 16:37
Diana Dohr schrieb:
Ein hoch auf die History:
So etwas hatten wir uns auch schon gedacht. Der Code sah wie folgt aus:
select_new_current = session.createSelect(contentStore.getEntityType().getName());
equal1 = new Equal("flag_current",false);
equal2 = new Equal("flag_used",false);
and1 = new And(equal1,equal2);
equal3 = new Equal("flag_current",null);
equal4 = new Equal("flag_used",null);
and2 = new And(equal3,equal4);
or = new OR();
or.add(and1);
or.add(and2);
select_new_current.setConstraint(or);
Wäre hier nicht ein NotEqual("flag_current", true) einfacher? Dann würde auch das Or entfallen.
ERROR 20.06.2012 16:44:49.274 (de.espirit.firstspirit.client.AWTDispatchingEventQueue): Error during dispatching of java.awt.event.MouseEvent[MOUSE_RELEASED,(97,32),absolute(651,721),button=1,modifiers=Button1,clickCount=1] on panel1
FSVersion=4.2.453.46978#2467;JDK=1.6.0_31 32bit Sun Microsystems Inc.;OS=Windows 7 6.1 x86;Date=20.06.2012 16:44:49
de.espirit.firstspirit.access.script.ExecutionException: Method Invocation session.executeQuery at line 68
at de.espirit.firstspirit.server.script.BeanshellScriptEngine$BeanshellExecutable.execute(BeanshellScriptEngine.java:120)
at de.espirit.firstspirit.client.gui.applications.ApplicationTabRegistry$IdentifiableExecutable.execute(ApplicationTabRegistry.java:150)
at de.espirit.firstspirit.common.ScriptUtil.execute(ScriptUtil.java:88)
at de.espirit.firstspirit.client.action.ScriptMenuAction$ScriptAction.actionPerformed(ScriptMenuAction.java:222)
at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
at javax.swing.AbstractButton.doClick(Unknown Source)
at javax.swing.plaf.basic.BasicMenuItemUI.doClick(Unknown Source)
at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(Unknown Source)
at java.awt.Component.processMouseEvent(Unknown Source)
at javax.swing.JComponent.processMouseEvent(Unknown Source)
at java.awt.Component.processEvent(Unknown Source)
at java.awt.Container.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
at java.awt.EventQueue.access$000(Unknown Source)
at java.awt.EventQueue$1.run(Unknown Source)
at java.awt.EventQueue$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.AccessControlContext$1.doIntersectionPrivilege(Unknown Source)
at java.security.AccessControlContext$1.doIntersectionPrivilege(Unknown Source)
at java.awt.EventQueue$2.run(Unknown Source)
at java.awt.EventQueue$2.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.AccessControlContext$1.doIntersectionPrivilege(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at de.espirit.firstspirit.client.AWTDispatchingEventQueue.defaultDispatchEvent(AWTDispatchingEventQueue.java:130)
at de.espirit.firstspirit.client.AWTDispatchingEventQueue._dispatchEvent(AWTDispatchingEventQueue.java:115)
at de.espirit.firstspirit.client.AWTDispatchingEventQueue.dispatchEvent(AWTDispatchingEventQueue.java:108)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
Caused by: de.espirit.or.ORException: Error code: 20000, state: 42X01
at de.espirit.or.impl.AbstractSessionHandler.createStatement(AbstractSessionHandler.java:1473)
at de.espirit.or.impl.AbstractSessionHandler.createStatement(AbstractSessionHandler.java:916)
at de.espirit.or.impl.AbstractSessionHandler.executeQuery(AbstractSessionHandler.java:704)
at de.espirit.or.impl.AbstractSessionHandler.executeQuery(AbstractSessionHandler.java:229)
at de.espirit.firstspirit.content.ContentManagerImpl$TemporalSessionHandler.executeQuery(ContentManagerImpl.java:1119)
at de.espirit.firstspirit.content.ContentManagerImpl.executeQuery(ContentManagerImpl.java:501)
at sun.reflect.GeneratedMethodAccessor39.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at de.espirit.firstspirit.io.DefaultServerHandler.callManager(DefaultServerHandler.java:62)
at de.espirit.firstspirit.server.io.handler.ManagerCall.doCall(ManagerCall.java:91)
at de.espirit.firstspirit.server.io.handler.CompactCall.handle(CompactCall.java:67)
at de.espirit.firstspirit.server.io.ManagerCallWorker.run(ManagerCallWorker.java:108)
at de.espirit.firstspirit.server.ExecutionManagerImpl$RunnableWrapper.call(ExecutionManagerImpl.java:553)
at de.espirit.firstspirit.server.ExecutionManagerImpl$ExtendedCallable.call(ExecutionManagerImpl.java:520)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at de.espirit.common.util.BoundedExecutorService$RunnableWrapper.run(BoundedExecutorService.java:419)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
at de.espirit.common.util.SuspendableThread.run(SuspendableThread.java:36)
Caused by: java.sql.SQLException: Syntax error: Encountered "AND" at line 1, column 106.
at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source)
at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedPreparedStatement.<init>(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.<init>(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.<init>(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedPreparedStatement40.<init>(Unknown Source)
at org.apache.derby.jdbc.Driver40.newEmbedPreparedStatement(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source)
at sun.reflect.GeneratedMethodAccessor31.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at de.espirit.or.impl.connection.ConnectionInvocationHandler.invoke(ConnectionInvocationHandler.java:73)
at $Proxy14.prepareStatement(Unknown Source)
at de.espirit.or.impl.AbstractSessionHandler.createStatement(AbstractSessionHandler.java:1464)
... 24 more
Caused by: java.sql.SQLException: Syntax error: Encountered "AND" at line 1, column 106.
at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown Source)
... 43 more
Caused by: ERROR 42X01: Syntax error: Encountered "AND" at line 1, column 106.
at org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
at org.apache.derby.impl.sql.compile.ParserImpl.parseStatement(Unknown Source)
at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source)
at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source)
at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedPreparedStatement.<init>(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.<init>(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.<init>(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedPreparedStatement40.<init>(Unknown Source)
at org.apache.derby.jdbc.Driver40.newEmbedPreparedStatement(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source)
at sun.reflect.GeneratedMethodAccessor31.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at de.espirit.or.impl.connection.ConnectionInvocationHandler.invoke(ConnectionInvocationHandler.java:73)
at $Proxy14.prepareStatement(Unknown Source)
at de.espirit.or.impl.AbstractSessionHandler.createStatement(AbstractSessionHandler.java:1464)
at de.espirit.or.impl.AbstractSessionHandler.createStatement(AbstractSessionHandler.java:916)
at de.espirit.or.impl.AbstractSessionHandler.executeQuery(AbstractSessionHandler.java:704)
at de.espirit.or.impl.AbstractSessionHandler.executeQuery(AbstractSessionHandler.java:229)
at de.espirit.firstspirit.content.ContentManagerImpl$TemporalSessionHandler.executeQuery(ContentManagerImpl.java:1119)
at de.espirit.firstspirit.content.ContentManagerImpl.executeQuery(ContentManagerImpl.java:501)
at sun.reflect.GeneratedMethodAccessor39.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at de.espirit.firstspirit.io.DefaultServerHandler.callManager(DefaultServerHandler.java:62)
at de.espirit.firstspirit.server.io.handler.ManagerCall.doCall(ManagerCall.java:91)
at de.espirit.firstspirit.server.io.handler.CompactCall.handle(CompactCall.java:67)
at de.espirit.firstspirit.server.io.ManagerCallWorker.run(ManagerCallWork
Trace message truncated for length over 10K
Wenn Sie den Code noch haben können Sie dann bitte mal nach dem "select_new_current.setConstraint(or);" ein select_new_current.getXML() als Logausgabe ausgeben und posten?
Diana Dohr schrieb:
Um zwischen released und current Daten zu unterscheiden, muss man sich die release-session holen.
Schema.getSession(boolean release);
Für den schnellen Weg über das Content2 nur die freigegeben Datensätze zu ermitteln gibt es im Moment keinen Weg.
Diese Änderung führt leider zu "merkwürdigen Verhalten" meiner DQ. Es tauchen bereits gelöschte Elemente wieder auf, nur weil diese noch das Flag "current" hatten. Wenn diese dann "endgültig" gelöscht sind und das "erst beste Element" welches freigegeben ist, das Flag "current" bekommen soll, bekomme ich folgende (extrem gekürzte) Fehlermeldung
java.lang.UnsupportedOperationException: Release an entity with a release session isn't supported
Es sieht für mich nicht so aus, als könne ich mit einer Session im "Release-Status" Daten freigeben. Die Manipulation an sich hat funktioniert...
Also auch hier: Schade. :smileysad:
In der Release-Session sind ja die freigegeben Daten, diese sind read-only. Wenn Sie also änderungen durchführen wollen muss hier wieder die current-Session benutzt werden. Das bei Verwendung der release-Session alte Datensätze auftauchen, lag daran, dass Sie nur im current Stand gelöscht wurden. Gelöscht werden muss - wie auch im JavaClient - immer in beiden.
0
Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.
Kommentare
19 Kommentare