| AbstractSqlLookupService cancels transaction on PostgresSQL 9.2 [message #1125755] |
Fri, 04 October 2013 17:18  |
Thomas Mangold Messages: 2 Registered: October 2013 |
Junior Member |
|
|
I set up a customized LookupService derived from AbstractSqlLookupService:
public class UnitLookupService extends AbstractSqlLookupService implements IUnitLookupService {
@ConfigProperty(ConfigProperty.SQL)
@Order(10)
@ConfigPropertyValue("null")
@Override
protected String getConfiguredSqlSelect() {
return "SELECT u.id"
+ " , u.name || ' (' || u.equi_quantity || ' g)'"
+ " FROM fdb.units u"
+ " WHERE 1=1 "
+ " <key> AND u.id = :key </key>"
+ " <text> AND UPPER(u.name) LIKE UPPER(:text || '%') </text>"
+ " <all> </all>";
}
}
The service works fine for key search but not for browsing all entries with the getDataByAll method. There is not an error nor an exception visible, but the Smartfield shows only an empty list. Typing in an existing text, inserts the approprieate key correcctly into the smartfield. Following the call in the debugger shows, that all the right rows are created on the server. Unfortunately receives the call later a tx.cancel() call out of a scout service tunnel. I could not figure out exactly where this call comes from.
I suppose it must depend somehow on the missing annotation for the @ConfigPropertyValue. Does anybody know, which value has to be annotated?
I'm using eclipse 4.3 installed local from eclipse.org, scout 3.9 and postgres 9.2 as database on Linux 32bit Fedora 19.
|
|
|
| Re: AbstractSqlLookupService cancels transaction on PostgresSQL 9.2 [message #1126021 is a reply to message #1125755] |
Sat, 05 October 2013 00:26   |
Jeremie Bresson Messages: 385 Registered: October 2011 |
Senior Member |
|
|
Are you on nightly build (Luna - Scout 3.10)?
We just removed the @ConfigPropertyValue... Bug 395132
Our analysis has shown that the Annotation wasn't used.
-> That something we will need to verify next week.
Can you try with our last Luna release: 3.10.0 M2?
You can find the EPP Package here.
Or you can use the corresponding update site.
Quote:The service works fine for key search but not for browsing all entries with the getDataByAll method. There is not an error nor an exception visible, but the Smartfield shows only an empty list.
Can you check in the server console (log)? What SQL Query is executed? Does it seems OK?
Can you debug? Set a breakpoint at:
org.eclipse.scout.rt.server.services.lookup.AbstractSqlLookupService.getDataByAll(LookupCall)
What is the content of LookupRow[] rows, before it is returned?
[Updated on: Sat, 05 October 2013 01:19] Report message to a moderator
|
|
|
| Re: AbstractSqlLookupService cancels transaction on PostgresSQL 9.2 [message #1126610 is a reply to message #1126021] |
Sat, 05 October 2013 15:33   |
Thomas Mangold Messages: 2 Registered: October 2013 |
Junior Member |
|
|
I'm still using scout 3.9.1 distributed with Eclipse 4.3 and can't download the 3.10 version because of a slow internet connection at the place I'm staying at the moment,
But the query seems absolut correct:
SQL with binds:
SELECT U.ID,
U.NAME || ' (' || U.EQUI_QUANTITY || ' g)'
AS "lookup_name"
FROM FDB.UNITS U
WHERE 1 = 1
Pasted into the SQL editor of pgadmin3 it delivers the expected result.
Debugging AbstractSqlLookupService.getDataByAll(LookupCall) delivers still the right result in the rows variable of the return statement.
The Problem occurs later in ActiveTransactionRegistry.unregister(ITransaction tx)
There in the debugger the transaction has suddenly the m_cancelled property set to true. May be this is only an artefact of debugging because i must leave the SmartField with the mousepointer to step on.
[Updated on: Sat, 05 October 2013 15:57] Report message to a moderator
|
|
|
| Re: AbstractSqlLookupService cancels transaction on PostgresSQL 9.2 [message #1127933 is a reply to message #1126610] |
Mon, 07 October 2013 02:48   |
Jeremie Bresson Messages: 385 Registered: October 2011 |
Senior Member |
|
|
Thomas Mangold wrote on Sat, 05 October 2013 21:33I'm still using scout 3.9.1 distributed with Eclipse 4.3 and can't download the 3.10 version because of a slow internet connection at the place I'm staying at the moment
Stay at this version. It should be OK.
I guess it has nothing to do with @ConfigPropertyValue.
Thomas Mangold wrote on Fri, 04 October 2013 23:18I'm using eclipse 4.3 installed local from eclipse.org, scout 3.9 and postgres 9.2 as database on Linux 32bit Fedora 19.
Maybe there is a problem with Fedora.
Thomas Mangold wrote on Sat, 05 October 2013 21:33
Debugging AbstractSqlLookupService.getDataByAll(LookupCall) delivers still the right result in the rows variable of the return statement.
The Problem occurs later in ActiveTransactionRegistry.unregister(ITransaction tx)
There in the debugger the transaction has suddenly the m_cancelled property set to true. May be this is only an artefact of debugging because i must leave the SmartField with the mousepointer to step on.
If you want to debug it futher, you could devide the problem: I suggest to test it without a database dependency.
Can you try an other implementation for your LookupService extending AbstractLookupService instead of AbstractSqlLookupService. For the different functions getDataByKey(), getDataByText(), getDataByAll(), just return array of LookupRows:
public LookupRow[] getDataByAll(LookupCall call) throws ProcessingException {
return new LookupRow[]{
new LookupRow(1L, "text by all 1"),
new LookupRow(2L, "text by all 2"),
new LookupRow(3L, "text by all 3")
};
}
This service can be registered this service in the server. If this is still not working, it would be interesting to register the service in the client (you can verify if this has something to do with the client/server communication).
.
|
|
|
| Re: AbstractSqlLookupService cancels transaction on PostgresSQL 9.2 [message #1128021 is a reply to message #1127933] |
Mon, 07 October 2013 04:48  |
André Lohrenz Messages: 4 Registered: March 2013 |
Junior Member |
|
|
It might be that you see your transaction is being canceled on debugging is not a problem of your LookupCall, but one of the combination of debugging a SmartField. I have seen this effect too:
1. You place a breakpoint in your code.
2. You click on the magnifier glass of the smartfield.
3. This triggers the lookup and thereby the breakpoint which changes the active window from your Scout application over to Eclipse.
4. This in turn lets the Scout runtime cancel the lookup that is in progress, because Scout sees that it doesn't have to (or cannot) show the lookup results and therefore doesn't even have to compute the results.
It appears this applies to any action in the GUI that would navigate away from the SmartField while the calculation is in progress: Changing the active application, clicking into another field, pressing the TAB-key etc. It's a smart feature under normal circumstances, because it avoids unecessary lookup action (like querying the database), but in the context of debugging a SmartField it is somewhat an annoyance. The workaround for me normally is to place the breakpoint "further down" the call stack, when the results are already calculated, or at a place where I can inspect the variables I need to.
|
|
|
Powered by
FUDForum. Page generated in 0.01658 seconds