Solved: Re: Scripting-Frage - Page 2

rbitdd · ‎06-06-2012

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...

broszeit · ‎06-11-2012

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

rbitdd · ‎06-11-2012

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

broszeit · ‎06-11-2012

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

tklein · ‎06-11-2012

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

rbitdd · ‎06-20-2012

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

tklein · ‎06-20-2012

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.

gockel · ‎06-20-2012

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());

rbitdd · ‎06-20-2012

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.. )

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.

tklein · ‎06-20-2012

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.

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.