JDOQL- (Kodo)SQL

Can somebody explain why i've received such defferent sql from nearly
identical jdoql queries? This jdoql filters differ in only one operator -
in the first filter we have OR (||) and in the second - AND (&&).
The sql, that was generated using second filter is incorrect.
JDOfilter = (properties.contains(prop) && (prop.propertyInfo.key ==
"mamba") && (prop.value == "umba")) || (properties.contains(prop) &&
(prop.propertyInfo.key == "description") && (prop.value != null))
SELECT DISTINCT t0.PK, t0.JDOLOCKX, t0.DESCRIPTION, t0.ID, t0.NAME FROM
PROPERTY t1, PROPERTY t3, PROPERTY_INFO t2, SERVICEINFO t0 WHERE (((t2.KEY
= ? AND t1.VALUE = ?) AND t0.PK = t1.SERVICEINFOX AND t1.PROPERTYINFOX =
t2.PK) OR ((t2.KEY = ? AND (t3.VALUE IS NOT NULL)) AND t0.PK =
t1.SERVICEINFOX AND t0.PK = t3.SERVICEINFOX AND t1.PROPERTYINFOX = t2.PK))
JDOfilter = (properties.contains(prop) && (prop.propertyInfo.key ==
"mamba") && (prop.value == "umba")) && (properties.contains(prop) &&
(prop.propertyInfo.key == "description") && (prop.value != null))
SELECT DISTINCT t0.PK, t0.JDOLOCKX, t0.DESCRIPTION, t0.ID, t0.NAME FROM
PROPERTY t1, PROPERTY t3, PROPERTY_INFO t2, SERVICEINFO t0 WHERE (((t2.KEY
= ? AND t1.VALUE = ?) AND (t2.KEY = ? AND (t3.VALUE IS NOT NULL))) AND
t0.PK = t1.SERVICEINFOX AND t0.PK = t3.SERVICEINFOX AND t1.PROPERTYINFOX =
t2.PK)

Oleh-
Can you try out these queries with the current 2.5.0 beta? I believe it
will probably address the issue.
In article <b5a45f$mme$[email protected]>, Oleh wrote:
Can somebody explain why i've received such defferent sql from nearly
identical jdoql queries? This jdoql filters differ in only one operator -
in the first filter we have OR (||) and in the second - AND (&&).
The sql, that was generated using second filter is incorrect.
JDOfilter = (properties.contains(prop) && (prop.propertyInfo.key ==
"mamba") && (prop.value == "umba")) || (properties.contains(prop) &&
(prop.propertyInfo.key == "description") && (prop.value != null))
SELECT DISTINCT t0.PK, t0.JDOLOCKX, t0.DESCRIPTION, t0.ID, t0.NAME FROM
PROPERTY t1, PROPERTY t3, PROPERTY_INFO t2, SERVICEINFO t0 WHERE (((t2.KEY
= ? AND t1.VALUE = ?) AND t0.PK = t1.SERVICEINFOX AND t1.PROPERTYINFOX =
t2.PK) OR ((t2.KEY = ? AND (t3.VALUE IS NOT NULL)) AND t0.PK =
t1.SERVICEINFOX AND t0.PK = t3.SERVICEINFOX AND t1.PROPERTYINFOX = t2.PK))
JDOfilter = (properties.contains(prop) && (prop.propertyInfo.key ==
"mamba") && (prop.value == "umba")) && (properties.contains(prop) &&
(prop.propertyInfo.key == "description") && (prop.value != null))
SELECT DISTINCT t0.PK, t0.JDOLOCKX, t0.DESCRIPTION, t0.ID, t0.NAME FROM
PROPERTY t1, PROPERTY t3, PROPERTY_INFO t2, SERVICEINFO t0 WHERE (((t2.KEY
= ? AND t1.VALUE = ?) AND (t2.KEY = ? AND (t3.VALUE IS NOT NULL))) AND
t0.PK = t1.SERVICEINFOX AND t0.PK = t3.SERVICEINFOX AND t1.PROPERTYINFOX =
t2.PK)--
Marc Prud'hommeaux [email protected]
SolarMetric Inc. http://www.solarmetric.com

Similar Messages

Using parameter in ext:caseInsStarts

Hi!
A am using Kodo Enterprise Edition 2.3.4 and Oracle 8.1.7.
It seems that I found a bug in these JDOQL Kodo extensions:
ext:caseInsStarts , ext:caseInsEnds and ext:caseInsContains.
Consider this JDOQL:
this.securityName.ext:caseInsContains(par_0),
where par_0 is declared as:
java.lang.String par_0
and provided value is:
[2002-12-16/13:50:15.844]
The resulting SQL statement looks like:
[ C:5800214; S:6130493; T:7921983; D:16.12.02 13:51 ] prepared statement:
SELECT some_columns
FROM SECURITY t0
WHERE UPPER (t0.SECURITYNAME) LIKE UPPER ('%java.lang.Object@539c9f%')
ORDER BY t0.SECURITYNAME ASC
So, the problem is that argument of LIKE clause is
'%java.lang.Object@539c9f%' instead of '?'.
I did not have this problem before I introduced parameter declaration in
JDOQL.
Regards,
Zoran.

Thanks for the report. Our upcoming 2.5 release has a revamped query engine
with more powerful extensions. This particular bug will also be fixed.

JDOQL Correlated Subquery - Bad SQL

Hi,
When I execute a JDOQL correlated subquery, the generated SQL is either
invalid or incorrect. Exactly what happens depends on the exact query, and
on the target database type, but I believe it all stems from the same
problem, which has to do with table aliasing.
If you need further details to reproduce this, please let me know. I'll be
glad to help in any way I can to get this situation remedied quickly, as I
am depending on this functionality. I have a test application to
demonstrate the problem.
I'm using Kodo 3.3.3 and application identity.
Paul Mogren
CommerceHub

For the record, this is in part due to a bug in Kodo's SQL92 joining.
See http://bugzilla.solarmetric.com/show_bug.cgi?id=1156
-Patrick
Paul Mogren wrote:
Certainly... Here's a simple example using Microsoft's JDBC Driver for SQL
Server 2000, and kodo.jdbc.sql.SQLServerDictionary, which produces invalid
SQL.
The query:
pm.newQuery(Container.class,
"(select from Entry entry where entries.contains(entry) &&
entry.containedId != 1).isEmpty()");
The classes:
class Contained {
private int id; //pk
class Container {
private int id; //pk
private Set entries = new HashSet(); //<Entry>
class Entry {
private int containerId; //pk
private int containedId; //pk
private Container container; //persistent-redundant
private Contained contained; //persistent-redundant
The result:
Incorrect syntax near the keyword 'WHERE'. {prepstmnt 31598780 SELECT
t0.container_id, t0.lock FROM WHERE (NOT EXISTS (SELECT DISTINCT
t2.contained_id, t2.container_id FROM dbo.entry t2 WHERE (t1.contained_id
= t2.contained_id AND t1.container_id = t2.container_id AND
t2.contained_id <> ?) AND t0.container_id = t1.container_id))
[params=(int) 1]} [code=156, state=HY000]
Patrick Linskey wrote:
Hi Paul,
Kodo's correlated subquery support does have some known limitations. Can
you post a sample JDOQL statement + corresponding SQL statement?
-Patrick
Paul Mogren wrote:
Hi,
When I execute a JDOQL correlated subquery, the generated SQL is either
invalid or incorrect. Exactly what happens depends on the exact query, and
on the target database type, but I believe it all stems from the same
problem, which has to do with table aliasing.
If you need further details to reproduce this, please let me know. I'll be
glad to help in any way I can to get this situation remedied quickly, as I
am depending on this functionality. I have a test application to
demonstrate the problem.
I'm using Kodo 3.3.3 and application identity.
Paul Mogren
CommerceHub

Kodo jdoql oracle problem

Hi there,
In my project, I have a jdoql query (select column1 from table1 where column2 == ''). It works fine with DB2 since DB2 supports empty string. When I moved it to oracle, the query doesn't get translated into something like (select column1 from table1 where column2 is null).
I am using openjpa.jdbc.sql.oracleDictionary in kodo property.
What are my options to handle this problem ?
kodo.log:
1024786 TRACE [WorkerThread#0[127.0.0.1:4318]] openjpa.jdbc.SQL - <t 981328, conn 5861567> executing prepstmnt 10850513
SELECT t0.TIMEFRAME
FROM VM0610 t0
WHERE t0.SITE = ?
[params=(String) ]

Sasha-
I can't seem to reproduce this problem, either in the 2.5 or
upcoming 2.3.0 version. My test case is very simple: I have
an object that has a HashSet of Strings, I save the object with
10 entries, retrieve it (both with the same PM and a new one),
and the 10 entries still exist. Can you try this test case,
and see if it works? If it does, can you send us as much
of your code as possible, so we can try to reproduct it?
Also, any additional information you can enter into the
bug report would be useful:
https://bugzilla.solarmetric.com/show_bug.cgi?id=198
Sasha Haghani <[email protected]> wrote:
Does anyone know of a problem with HashSets in recent releases of Kodo? We
are currently working with 2.2.4 SP 1 and are running into the following
problem...
An existing persistence capable class (Group) had a number of simple fields
in it, as well as on HashSet, and a few HashMaps. The HashSet had Strings in
it, while the HashMaps are String to String, and String to complex objects.
All persistence of Group was occurring properly in the past. A recent
version of Kodo has introduced a problem where the HashSet contents
(Strings) are no longer persisted, but the simple fields and HashMap
contents are still being persisted ok. What is also interesting is that
there seems to be a relationship to the age of the Group object. Existing
Group objects seem to persist cleanly. New Group objects, which have been
made persistent and have been written out to the db (so should really be
identical to existing ones), exhibit the problem with the HashSets.
Can you shed any light on this? Thanks.
Sasha Haghani--
Marc Prud'hommeaux [email protected]
SolarMetric Inc. http://www.solarmetric.com
Kodo Java Data Objects Full featured JDO: eliminate the SQL from your code

SQL Statement batching in Kodo 2.5

Can statement batching in Kodo 2.5 be observed in sql statement logs? How do
I know whether it does batching or not?

Yeah, it's really quite annoying that you can't get this info from Oracle.
At some point soon, we'll probably add an option to use statement batching
anyways, at the cost of the correct behavior when optimistic lock
exceptions occur.
-Patrick
On Fri, 04 Jul 2003 17:04:46 -0400, Alex Roytman wrote:
Oracle!!
"Patrick Linskey" <[email protected]> wrote in message
news:[email protected]..
Yes; you'll see 'batching statement ...' show up in the SQL log.
What database do you use? We don't currently do any batching with Oracle,
as Oracle doesn't return useful information about which statements failed
if failures occurred.
-Patrick
On Fri, 04 Jul 2003 16:56:50 -0400, Alex Roytman wrote:
Can statement batching in Kodo 2.5 be observed in sql statement logs?
How do
I know whether it does batching or not?--
Patrick Linskey
SolarMetric Inc.
Patrick Linskey
SolarMetric Inc.

Kodo 3.4.1: how to limit # of sql query params when using collection param

Hi,
We have a problem when using Kodo 3.4.1 against SQL Server 2005, when we execute query:
 Query query = pm.newQuery( extent, "IdList.contains( this )" );
 query.declareParameters( "Collection IdList" );
 query.declareImports( "import java.util.Collection;" );
 return (List) query.execute( list );
We got:
com.microsoft.sqlserver.jdbc.SQLServerException: The incoming tabular data stream (TDS) remote procedure call (RPC) protocol stream is incorrect. Too many parameters were provided in this RPC request. The maximum is 2100.
at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDatabaseError(Unknown Source)
at com.microsoft.sqlserver.jdbc.SQLServerStatement.getNextResult(Unknown Source)
at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement.doExecutePreparedStatement(Unknown Source)
at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement$PrepStmtExecCmd.doExecute(Unknown Source)
at com.microsoft.sqlserver.jdbc.TDSCommand.execute(Unknown Source)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.executeCommand(Unknown Source)
at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeCommand(Unknown Source)
at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeStatement(Unknown Source)
at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement.executeQuery(Unknown Source)
at com.solarmetric.jdbc.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:354)
at com.solarmetric.jdbc.PoolConnection$PoolPreparedStatement.executeQuery(PoolConnection.java:341)
at com.solarmetric.jdbc.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:352)
at com.solarmetric.jdbc.LoggingConnectionDecorator$LoggingConnection$LoggingPreparedStatement.executeQuery(LoggingConnectionDecorator.java:1106)
at com.solarmetric.jdbc.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:352)
at kodo.jdbc.runtime.JDBCStoreManager$CancelPreparedStatement.executeQuery(JDBCStoreManager.java:1730)
at com.solarmetric.jdbc.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:339)
at kodo.jdbc.sql.Select.execute(Select.java:1581)
at kodo.jdbc.sql.Select.execute(Select.java:1533)
at kodo.jdbc.runtime.SelectResultObjectProvider.open(SelectResultObjectProvider.java:102)
at com.solarmetric.rop.EagerResultList.<init>(EagerResultList.java:22)
at kodo.query.AbstractQuery.execute(AbstractQuery.java:1081)
at kodo.query.AbstractQuery.executeWithArray(AbstractQuery.java:836)
at kodo.query.AbstractQuery.execute(AbstractQuery.java:799)
It seems that there're too many ids in the list, and Kodo didn't limit the # of sql parameters when craft the sql query. Is there a way to ask Kodo to use multiple queries with smaller # of sql parameters instead of using one big sql query?
Thanks

Hi,
Sadly, there is no way to do that in Kodo currently. The closest is the inClauseLimit DBDictionary setting, but that setting just breaks things up into multiple IN statements put together with an OR clause. In your case, it looks like the network transport, not the SQL parser, is complaining about size limits.
You could force the query to run in-memory, but that would probably be prohibitively slow, unless the data set that you're querying against is relatively small.
-Patrick

Kodo 4.0.1 wrong delete sql

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2900.2963" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV>Hello,</DIV>
<DIV>I have the following class:</DIV>
<DIV>
public class CurrencyRateList {


 private Map<Currency,
Double> rateList = new HashMap<Currency, Double>();
 public void
removeConversionRate(Currency cur) {

rateList.remove(cur);
 }


}
I've created and added a ValueHandler for
Currency.
calling
CurrencyRateList.removeConversionRate(Currency.getInstance("USD")) results
in the following sql:
DELETE FROM dbo.CURRE_RATELIST WHERE CURRENCYCODEKEY
= ? [params=(String) USD]
which will result in all USD currencies being deleted
from all CurrencyRateLists instead of one.
 
kind regards,
Christiaan</DIV></BODY></HTML>

This is a bug. We've fixed it internally for the next release. In the
meantime, you should be able to work around it by resetting the map
contents, such as:
pc.setMap(new HashMap(pc.getMap()));
pc.getMap().remove(key);
That will cause Kodo to completely delete and re-insert the map data in
the DB, rather than removing the single key. Obviously less efficient,
but it should at least work properly.
Thanks for the report. If you need to follow up with support on this
for patches, etc, reference CR #292916.

Jdoql sql error.. puzzled why it puts quotes in table name

I keep getting a jdoql error when running my entity bean.. basically, something is wrong with the sql command the entity bean passes to the database.. when i set the log file to "fine" and looked at the log file, this is the sql statement it passes to the driver:
SQL statement<select t0."id", t0."parent_category", t0."name", t0."available", t0."available_date" from "drs_category" t0 where t0."genotype" = ?> with input values:
I noticed that it put quotes between the table name!!! this will always give me a syntax error if i run this quote straight into the informix database.. the problem is, where do i tell it to take out the quotes since it's programmed into the jdoql class... btw, i am using an informix database

nevermind... i figured it out.. create file INFORMIX DYNAMIC SERVER.properties and put in appserv-cmp.jar ..add these lines to the file:
# default properties for Informix SQL generation
FOR_UPDATE=for update
LEFT_JOIN=, outer
RIGHT_JOIN=,
RIGHT_JOIN_PRE=outer
IS_NULL=\= NULL
IS_NOT_NULL=!= NULL
RTRIM=trim (trailing \" \" from
RTRIM_POST=)
QUOTE_CHAR_START=
QUOTE_CHAR_END=

Will Kodo EJB3 support SQL queries standard?

Hello,
Will Kodo EJB3 support SQL queries (via
EntityManager.createNativeQuery(...))
in the Standard Edition since native queries are part of the API? Or will
that functionality require Enterprise Edition or Performance Pack?
thanks and good luck in the new year,
dave

Currently, SQL queries require the enterprise edition. Whether this
will change for Kodo 4 final has not been decided. The safest route
would be to assume that it will not change.

Kodo 3.0 generates invalid SQL statement when deleting an instance

Hi,
kodo 3.0 generates an invalid SQL statement when deleting an instance
that has a one-many inverse unidirectional association.
All manipulations of the data go just fine except for the deletion of
instances of Whole without Parts. Kodo 3.0 generates the following SQL
statement UPDATE PART SET WHERE PARTID= ?.
This problem does not occur when using a bidirectional relationship
between Whole and Part. Is there an error in the mapping file somewhere?
Thanks in advance,
Stijn
database schema
<table name="PART">
<column name="PARTID" type="bigint"/>
<fk to-table="WHOLE">
<join column="PARTID" to-column="WHOLEID"/>
</fk>
</table>
<table name="WHOLE">
<column name="WHOLEID" type="bigint"/>
</table>
classes
public class Whole implements javax.jdo.InstanceCallbacks{
private java.util.Set parts = new java.util.HashSet();
public void jdoPreDelete {
//implements cascading delete
public class Part implements javax.jdo.InstanceCallbacks{
private int partid;
mapping
<class name="Whole">
<field name="parts">
<jdbc-field-map type="one-many" column.PARTID="PARTID"
ref-column.WHOLEID="PARTID" table="PART"/>
</field>

This bug is caused by the fact that your FK is using a column that is
not nullable (in this case, because it is also a PK column). It is
definitely a bug on our side, but I wanted to let our users know that
most one-sided one-many relations won't exhibit this problem.
Thank you for the report; we will try to correct the problem in an
upcoming release.

Howto create SQL DDL script using kodo 3?

How do I create a SQL script (DDL script) for my database using kodo 3?
I've looked everywhere and can't figure it out :-(
The deprecated/replaced schematool had an outputfile option that did the
trick.
However, there seems to be no such option for the new mappingtool?
Thanks
Jesper

Jesper Ladegaard wrote:
How do I create a SQL script (DDL script) for my database using kodo 3?
I've looked everywhere and can't figure it out :-(
The deprecated/replaced schematool had an outputfile option that did the
trick.
However, there seems to be no such option for the new mappingtool?
Thanks
JesperI think it works:
java kodo.jdbc.schema.SchemaTool -file ddl.sql -a createDB
or
java kodo.jdbc.schema.SchemaTool -file ddl.sql -a dropDB
Regards,
Vladimiras

Unit test fails after upgrading to Kodo 4.0.0 from 4.0.0-EA4

I have a group of 6 unit tests failing after upgrading to the new Kodo
4.0.0 (with BEA) from Kodo-4.0.0-EA4 (with Solarmetric). I'm getting
exceptions like the one at the bottom of this email. It seems to be an
interaction with the PostgreSQL driver, though I can't be sure. I
haven't changed my JDO configuration or the related classes in months
since I've been focusing on using the objects that have already been
defined. The .jdo, .jdoquery, and .java code are below the exception,
just in case there's something wrong in there. Does anyone have advice
as to how I might debug this?
Thanks,
Mark
Testsuite: edu.ucsc.whisper.test.integration.UserManagerQueryIntegrationTest
Tests run: 15, Failures: 0, Errors: 6, Time elapsed: 23.308 sec
Testcase:
testGetAllUsersWithFirstName(edu.ucsc.whisper.test.integration.UserManagerQueryIntegrationTest):
Caused an ERROR
The column index is out of range: 2, number of columns: 1.
<2|false|4.0.0> kodo.jdo.DataStoreException: The column index is out of
range: 2, number of columns: 1.
at
kodo.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:4092)
at kodo.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:82)
at kodo.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:66)
at kodo.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:46)
at
kodo.jdbc.kernel.SelectResultObjectProvider.handleCheckedException(SelectResultObjectProvider.java:176)
at
kodo.kernel.QueryImpl$PackingResultObjectProvider.handleCheckedException(QueryImpl.java:2460)
at
com.solarmetric.rop.EagerResultList.<init>(EagerResultList.java:32)
at kodo.kernel.QueryImpl.toResult(QueryImpl.java:1445)
at kodo.kernel.QueryImpl.execute(QueryImpl.java:1136)
at kodo.kernel.QueryImpl.execute(QueryImpl.java:901)
at kodo.kernel.QueryImpl.execute(QueryImpl.java:865)
at kodo.kernel.DelegatingQuery.execute(DelegatingQuery.java:787)
at kodo.jdo.QueryImpl.executeWithArray(QueryImpl.java:210)
at kodo.jdo.QueryImpl.execute(QueryImpl.java:137)
at
edu.ucsc.whisper.core.dao.JdoUserDao.findAllUsersWithFirstName(JdoUserDao.java:232)
at
edu.ucsc.whisper.core.manager.DefaultUserManager.getAllUsersWithFirstName(DefaultUserManager.java:252)
NestedThrowablesStackTrace:
org.postgresql.util.PSQLException: The column index is out of range: 2,
number of columns: 1.
at
org.postgresql.core.v3.SimpleParameterList.bind(SimpleParameterList.java:57)
at
org.postgresql.core.v3.SimpleParameterList.setLiteralParameter(SimpleParameterList.java:101)
at
org.postgresql.jdbc2.AbstractJdbc2Statement.bindLiteral(AbstractJdbc2Statement.java:2085)
at
org.postgresql.jdbc2.AbstractJdbc2Statement.setInt(AbstractJdbc2Statement.java:1133)
at
com.solarmetric.jdbc.DelegatingPreparedStatement.setInt(DelegatingPreparedStatement.java:390)
at
com.solarmetric.jdbc.PoolConnection$PoolPreparedStatement.setInt(PoolConnection.java:440)
at
com.solarmetric.jdbc.DelegatingPreparedStatement.setInt(DelegatingPreparedStatement.java:390)
at
com.solarmetric.jdbc.DelegatingPreparedStatement.setInt(DelegatingPreparedStatement.java:390)
at
com.solarmetric.jdbc.DelegatingPreparedStatement.setInt(DelegatingPreparedStatement.java:390)
at
com.solarmetric.jdbc.LoggingConnectionDecorator$LoggingConnection$LoggingPreparedStatement.setInt(LoggingConnectionDecorator.java:1
257)
at
com.solarmetric.jdbc.DelegatingPreparedStatement.setInt(DelegatingPreparedStatement.java:390)
at
com.solarmetric.jdbc.DelegatingPreparedStatement.setInt(DelegatingPreparedStatement.java:390)
at kodo.jdbc.sql.DBDictionary.setInt(DBDictionary.java:980)
at kodo.jdbc.sql.DBDictionary.setUnknown(DBDictionary.java:1299)
at kodo.jdbc.sql.SQLBuffer.setParameters(SQLBuffer.java:638)
at kodo.jdbc.sql.SQLBuffer.prepareStatement(SQLBuffer.java:539)
at kodo.jdbc.sql.SQLBuffer.prepareStatement(SQLBuffer.java:512)
at kodo.jdbc.sql.SelectImpl.execute(SelectImpl.java:332)
at kodo.jdbc.sql.SelectImpl.execute(SelectImpl.java:301)
at kodo.jdbc.sql.Union$UnionSelect.execute(Union.java:642)
at kodo.jdbc.sql.Union.execute(Union.java:326)
at kodo.jdbc.sql.Union.execute(Union.java:313)
at
kodo.jdbc.kernel.SelectResultObjectProvider.open(SelectResultObjectProvider.java:98)
at
kodo.kernel.QueryImpl$PackingResultObjectProvider.open(QueryImpl.java:2405)
at
com.solarmetric.rop.EagerResultList.<init>(EagerResultList.java:22)
at kodo.kernel.QueryImpl.toResult(QueryImpl.java:1445)
at kodo.kernel.QueryImpl.execute(QueryImpl.java:1136)
at kodo.kernel.QueryImpl.execute(QueryImpl.java:901)
at kodo.kernel.QueryImpl.execute(QueryImpl.java:865)
at kodo.kernel.DelegatingQuery.execute(DelegatingQuery.java:787)
at kodo.jdo.QueryImpl.executeWithArray(QueryImpl.java:210)
at kodo.jdo.QueryImpl.execute(QueryImpl.java:137)
at
edu.ucsc.whisper.core.dao.JdoUserDao.findAllUsersWithFirstName(JdoUserDao.java:232)
--- DefaultUser.java -------------------------------------------------
public class DefaultUser
implements User
/** The account username. */
private String username;
/** The account password. */
private String password;
/** A flag indicating whether or not the account is enabled. */
private boolean enabled;
/** The authorities granted to this account. */
private Set<Authority> authorities;
/** Information about the user, including their name and text that
describes them. */
private UserInfo userInfo;
/** The set of organizations where this user works. */
private Set<Organization> organizations;
--- DefaultUser.jdo --------------------------------------------------
<?xml version="1.0"?>
<!DOCTYPE jdo PUBLIC
"-//Sun Microsystems, Inc.//DTD Java Data Objects Metadata 2.0//EN"
"http://java.sun.com/dtd/jdo_2_0.dtd">
<jdo>
<package name="edu.ucsc.whisper.core">
<sequence name="user_id_seq"
factory-class="native(Sequence=user_id_seq)"/>
<class name="DefaultUser" detachable="true"
table="whisper_user" identity-type="datastore">
<datastore-identity sequence="user_id_seq" column="userId"/>
<field name="username">
<column name="username" length="80" jdbc-type="VARCHAR" />
</field>
<field name="password">
<column name="password" length="40" jdbc-type="CHAR" />
</field>
<field name="enabled">
<column name="enabled" />
</field>
<field name="userInfo" persistence-modifier="persistent"
default-fetch-group="true" dependent="true">
<extension vendor-name="jpox"
key="implementation-classes"
value="edu.ucsc.whisper.core.DefaultUserInfo" />
<extension vendor-name="kodo"
key="type"
value="edu.ucsc.whisper.core.DefaultUserInfo" />
</field>
<field name="authorities" persistence-modifier="persistent"
table="user_authorities"
default-fetch-group="true">
<collection
element-type="edu.ucsc.whisper.core.DefaultAuthority" />
<join column="userId" delete-action="cascade"/>
<element column="authorityId" delete-action="cascade"/>
</field>
<field name="organizations" persistence-modifier="persistent"
table="user_organizations" mapped-by="user"
default-fetch-group="true" dependent="true">
<collection
element-type="edu.ucsc.whisper.core.DefaultOrganization"
dependent-element="true"/>
<join column="userId"/>

</field>
</class>
</package>
</jdo>
--- DefaultUser.jdoquery ---------------------------------------------
<?xml version="1.0"?>
<!DOCTYPE jdo PUBLIC
"-//Sun Microsystems, Inc.//DTD Java Data Objects Metadata 2.0//EN"
"http://java.sun.com/dtd/jdo_2_0.dtd">
<jdo>
<package name="edu.ucsc.whisper.core">
<class name="DefaultUser">
<query name="UserByUsername"
language="javax.jdo.query.JDOQL"><![CDATA[
SELECT UNIQUE FROM edu.ucsc.whisper.core.DefaultUser
WHERE username==searchName
PARAMETERS java.lang.String searchName
]]></query>
<query name="DisabledUsers"
language="javax.jdo.query.JDOQL"><![CDATA[
SELECT FROM edu.ucsc.whisper.core.DefaultUser WHERE
enabled==false
]]></query>
<query name="EnabledUsers"
language="javax.jdo.query.JDOQL"><![CDATA[
SELECT FROM edu.ucsc.whisper.core.DefaultUser WHERE
enabled==true
]]></query>
<query name="CountUsers"
language="javax.jdo.query.JDOQL"><![CDATA[
SELECT count( this ) FROM edu.ucsc.whisper.core.DefaultUser
]]></query>
</class>
</package>
</jdo>

I'm sorry, I have no idea. I suggest sending a test case that
reproduces the problem to support.

Using a date field in a JDOQL query crashes

Hello:
I am trying to use a date field in a JDOQL filter. It appears from the
log file that the date is not being substituted into the SQL.
It is not clear from the JDOQL spec how to do date queries.... doing date
queries in SQL involves several special operators, yet the
JDOQL defines the ">" and "<" operators as working on dates....and there is
no mention of date specific operators so I am hoping that I
can do a filter where I compare a date to an input parameter date using the
">" and "<" operators...
I have enclosed a copy of my driver code, followed by an except of my class
that contains the date, followed by the kodo exception log
I can't see where I am doing anything that violates the JDOQL spec and I
don't see any other way of doing date comparisions.
Brian
Here is the driver code that I am attempting:
public void getDateRange ()
PersistenceManager pm = JDOFactory.getPersistenceManager ();
String filter = "leafDates.contains (cdate) & cdate.statusName ==
myStatus & cdate.datePhaseStarted > myDate";
Date date = new Date ();
Calendar calendar = new GregorianCalendar (TimeZone.getDefault ());
calendar.set (2002, Calendar.DECEMBER, 26);
date=calendar.getTime();
Extent extent = pm.getExtent (LeafBase.class, false);
Query query = pm.newQuery (LeafBase.class, filter);
query.declareImports ("import aqueduct.*; import java.util.Date");
query.declareVariables ("aqueduct.LeafDate cdate; Date myDate");
query.declareParameters ("String myStatus");
System.out.println ("dated used = " + date);
Collection results = (Collection) query.execute ("closed", date);
Iterator iter = results.iterator ();
while (iter.hasNext () ) {
LeafBase myLeaf = (LeafBase) iter.next ();
System.out.println ("My leaf = " + myLeaf);
pm.close ();
Here is the class:
public class LeafDate implements Serializable
// *******The Attributes***************
private Date datePhaseStarted = null;
private boolean isEstimatedDate = false;
//mark this as non-persistent in the JDO metadata
private StatusType status = null;
//put here to enable one-to-many mapping using a single table in JDO
private LeafBase parent = null;
Here is the error I am getting:
C:\bcs\jdo\kodo-jdo-2.4.0\aqueduct>java aqueduct.DealMaint dated used = Thu
Dec 26 08:47:33 CST 2002
Exception in thread "main" javax.jdo.JDODataStoreException:
com.solarmetric.kodo.impl.jdbc.sql.SQLExceptionWrapper:
[SQL=SELECT DISTINCT t0.ID, t0.JDOCLASS, t0.IS_CONFLICT, t0.CURRENCYX,
t0.DEALPARENTX, t0.PARENTX, t0.PRODUCTKIND, t0.T_SIZE, t0.STATUSNAME FROM
JDO_DATE t1, JDO_LEAF t0 WHERE ((t1.STATUSNAME = 'closed' AND t1.DATESTARTED
*variable*) AND t0.ID = t1.PARENTX) PRE=SELECT DISTINCT t0.ID,
t0.JDOCLASS, t0.IS_CONFLICT, t0.CURRENCYX, t0.DEALPARENTX, t0.PARENTX,
t0.PRODUCTKIND, t0.T_SIZE, t0.STATUSNAME FROM JDO_DATE t1, JDO_LEAF t0 WHERE
((t1.STATUSNAME = ? AND t1.DATESTARTED > *variable*) AND t0.ID =
t1.PARENTX)
ORA-00936: missing expression
[code=936;state=42000]
NestedThrowables:com.solarmetric.kodo.impl.jdbc.sql.SQLExceptionWrapper:
[SQL=SELECT DISTINCT t0.ID, t0.JDOCLASS, t0.IS_CONFLICT, t0.CURRENCYX,
t0.DEALPA RENTX, t0.PARENTX, t0.PRODUCTKIND, t0.T_SIZE, t0.STATUSNAME FROM
JDO_DATE t1, JD O_LEAF t0 WHERE ((t1.STATUSNAME = 'closed' AND
t1.DATESTARTED > *variable*) AND t0.ID = t1.PARENTX)] [PRE=SELECT DISTINCT
t0.ID, t0.JDOCLASS, t0.IS_CONFLICT, t0.CURRENCYX, t0.DEALPA RENTX,
t0.PARENTX, t0.PRODUCTKIND, t0.T_SIZE, t0.STATUSNAME FROM JDO_DATE t1, JD
O_LEAF t0 WHERE ((t1.STATUSNAME = ? AND t1.DATESTARTED > *variable*) AND
t0.ID = t1.PARENTX)]
ORA-00936: missing expression
at
com.solarmetric.kodo.impl.jdbc.runtime.SQLExceptions.throwDataStore(SQLExcep
tions.java:23)
at
com.solarmetric.kodo.impl.jdbc.runtime.JDBCStoreManager.executeQuery(JDBCSto
reManager.java:742)
at
com.solarmetric.kodo.impl.jdbc.runtime.JDBCQuery.executeQuery(JDBCQuery.java
:92)
at com.solarmetric.kodo.query.QueryImpl.executeWithMap(QueryImpl.java:792)
at com.solarmetric.kodo.query.QueryImpl.executeWithArray(QueryImpl.java:668)
at com.solarmetric.kodo.query.QueryImpl.execute(QueryImpl.java:623)
at aqueduct.DealMaint.getDateRange(DealMaint.java:523)
at
aqueduct.DealMaint.main(DealMaint.java:35)NestedThrowablesStackTrace:java.sq
l.SQLException:
ORA-00936: missing expression
at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:169)
at oracle.jdbc.ttc7.TTIoer.processError(TTIoer.java:208)
at oracle.jdbc.ttc7.Oall7.receive(Oall7.java:543)
at oracle.jdbc.ttc7.TTC7Protocol.doOall7(TTC7Protocol.java:1405)
at oracle.jdbc.ttc7.TTC7Protocol.parseExecuteDescribe(TTC7Protocol.java:643)
at
oracle.jdbc.driver.OracleStatement.doExecuteQuery(OracleStatement.java:1819)
at
oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java
:2015)
at
oracle.jdbc.driver.OraclePreparedStatement.doScrollPstmtExecuteUpdate(Oracle
PreparedStatement.java:3021)
at
oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedState
ment.java:416)
at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePrepare

Oh, thanks for pointing this out.... I got caught up in trying to figure out
the date issues, I missed the obvious.
Brian
"Patrick Linskey" <[email protected]> wrote in message
news:[email protected]...
Brian,
The problem is that you're declaring myDate as a variable instead of a
parameter. Yes, we should be doing better error checking. But that's the
problem.
So, change your declareVariables() and declareParameters() statements
accordingly, and all should work out.
-Patrick
Brian Smith wrote:
Here is the driver code that I am attempting:
public void getDateRange ()
PersistenceManager pm = JDOFactory.getPersistenceManager ();
String filter = "leafDates.contains (cdate) & cdate.statusName ==
myStatus & cdate.datePhaseStarted > myDate";
Date date = new Date ();
Calendar calendar = new GregorianCalendar (TimeZone.getDefault
>>
calendar.set (2002, Calendar.DECEMBER, 26);
date=calendar.getTime();
Extent extent = pm.getExtent (LeafBase.class, false);
Query query = pm.newQuery (LeafBase.class, filter);
query.declareImports ("import aqueduct.*; importjava.util.Date");
>>
query.declareVariables ("aqueduct.LeafDate cdate; Date myDate");
query.declareParameters ("String myStatus");
System.out.println ("dated used = " + date);
Collection results = (Collection) query.execute ("closed", date);
Iterator iter = results.iterator ();
while (iter.hasNext () ) {
LeafBase myLeaf = (LeafBase) iter.next ();
System.out.println ("My leaf = " + myLeaf);
pm.close ();
>
Here is the class:
public class LeafDate implements Serializable
// *******The Attributes***************
private Date datePhaseStarted = null;
private boolean isEstimatedDate = false;
//mark this as non-persistent in the JDO metadata
private StatusType status = null;
//put here to enable one-to-many mapping using a single table in JDO
private LeafBase parent = null;
>
Here is the error I am getting:
C:\bcs\jdo\kodo-jdo-2.4.0\aqueduct>java aqueduct.DealMaint dated used
= Thu
Dec 26 08:47:33 CST 2002
Exception in thread "main" javax.jdo.JDODataStoreException:
com.solarmetric.kodo.impl.jdbc.sql.SQLExceptionWrapper:
[SQL=SELECT DISTINCT t0.ID, t0.JDOCLASS, t0.IS_CONFLICT, t0.CURRENCYX,
t0.DEALPARENTX, t0.PARENTX, t0.PRODUCTKIND, t0.T_SIZE, t0.STATUSNAMEFROM> > JDO_DATE t1, JDO_LEAF t0 WHERE ((t1.STATUSNAME = 'closed' AND> > t1.DATESTARTED> >> > >*variable*) AND t0.ID = t1.PARENTX) [PRE=SELECT DISTINCT t0.ID,
>
ORA-00936: missing expression
[code=936;state=42000]
NestedThrowables:com.solarmetric.kodo.impl.jdbc.sql.SQLExceptionWrapper:
[SQL=SELECT DISTINCT t0.ID, t0.JDOCLASS, t0.IS_CONFLICT, t0.CURRENCYX,
t0.DEALPA RENTX, t0.PARENTX, t0.PRODUCTKIND, t0.T_SIZE, t0.STATUSNAMEFROM
JDO_DATE t1, JD O_LEAF t0 WHERE ((t1.STATUSNAME = 'closed' AND
t1.DATESTARTED > variable) AND t0.ID = t1.PARENTX)] [PRE=SELECTDISTINCT
t0.ID, t0.JDOCLASS, t0.IS_CONFLICT, t0.CURRENCYX, t0.DEALPA RENTX,
t0.PARENTX, t0.PRODUCTKIND, t0.T_SIZE, t0.STATUSNAME FROM JDO_DATE t1,JD
O_LEAF t0 WHERE ((t1.STATUSNAME = ? AND t1.DATESTARTED > variable) AND
t0.ID = t1.PARENTX)]
ORA-00936: missing expression
at
com.solarmetric.kodo.impl.jdbc.runtime.SQLExceptions.throwDataStore(SQLExcep
tions.java:23)
at
com.solarmetric.kodo.impl.jdbc.runtime.JDBCStoreManager.executeQuery(JDBCSto
reManager.java:742)
at
com.solarmetric.kodo.impl.jdbc.runtime.JDBCQuery.executeQuery(JDBCQuery.java
:92)
atcom.solarmetric.kodo.query.QueryImpl.executeWithMap(QueryImpl.java:792)
>>
at
com.solarmetric.kodo.query.QueryImpl.executeWithArray(QueryImpl.java:668)
>>
at com.solarmetric.kodo.query.QueryImpl.execute(QueryImpl.java:623)
at aqueduct.DealMaint.getDateRange(DealMaint.java:523)
at
aqueduct.DealMaint.main(DealMaint.java:35)NestedThrowablesStackTrace:java.sq
l.SQLException:
ORA-00936: missing expression
at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:169)
at oracle.jdbc.ttc7.TTIoer.processError(TTIoer.java:208)
at oracle.jdbc.ttc7.Oall7.receive(Oall7.java:543)
at oracle.jdbc.ttc7.TTC7Protocol.doOall7(TTC7Protocol.java:1405)
at
oracle.jdbc.ttc7.TTC7Protocol.parseExecuteDescribe(TTC7Protocol.java:643)
>>
at
oracle.jdbc.driver.OracleStatement.doExecuteQuery(OracleStatement.java:1819)
>>
at
oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java
:2015)
at
oracle.jdbc.driver.OraclePreparedStatement.doScrollPstmtExecuteUpdate(Oracle
PreparedStatement.java:3021)
at
oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedState
ment.java:416)
at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePrepare
Patrick Linskey [email protected]
SolarMetric Inc. http://www.solarmetric.com

Relational queries through JDBC with the help of Kodo's metadata for O/R mapping

Due to JDOQL's limitations (inability to express joins, when relationships
are not modeled as object references), I find myself needing to drop down to
expressing some queries in SQL through JDBC. However, I still want my Java
code to remain independent of the O/R mapping. I would like to be able to
formulate the SQL without hardcoding any knowledge of the relational table
and column names, by using Kodo's metadata. After poking around the Kodo
Javadocs, it appears as though the relevant calls are as follows:
ClassMetaData cmd = ClassMetaData.getInstance(MyPCObject.class, pm);
FieldMetaData fmd = cmd.getDeclaredField( "myField" );
PersistenceManagerFactory pmf = pm.getPersistenceManagerFactory();
JDBCConfiguration conf = (JDBCConfiguration)
((EEPersistenceManagerFactory)pmf).getConfiguration();
ClassResolver resolver = pm.getClassResolver(MyPCObject.class);
Connector connector = new PersistenceManagerConnector(
(PersistenceManagerImpl) pm );
DBDictionary dict = conf.getDictionary( connector );
FieldMapping fm = ClassMapping.getFieldMapping(fmd, conf, resolver, dict);
Column[] cols = fm.getDataColumns();
Does that look about right?
Here's what I'm trying to do:
class Foo
String name; // application identity
String bar; // foreign key to Bar
class Bar
String name; // application identity
int weight;
Let's say I want to query for all Foo instances for which its bar.weight >
100. Clearly this is trivial to do in JDOQL, if Foo.bar is an object
reference to Bar. But there are frequently good reasons for modeling
relationships as above, for example when Foo and Bar are DTOs exposed by the
remote interface of an EJB. (Yeah, yeah, I'm lazy, using my
PersistenceCapable classes as both the DAOs and the DTOs.) But I still want
to do queries that navigate the relationship; it would be nice to do it in
JDOQL directly. I will also want to do other weird-ass queries that would
definitely only be expressible in SQL. Hence, I'll need Kodo's O/R mapping
metadata.
Is there anything terribly flawed with this logic?
Ben

I have a one point before I get to this:
There is nothing wrong with using PC instances as both DAO and DTO
objects. In fact, I strongly recommend this for most J2EE/JDO design.
However, there should be no need to expose the foreign key values... use
application identity to quickly reconstitute an object id (which can in
turn find the persistent version), or like the j2ee tutorial, store the
object id in some form (Object or String) and use that to re-find the
matching persistent instance at the EJB tier.
Otherwise, there is a much easier way of finding ClassMapping instances
and in turn FieldMapping instances (see ClassMapping.getInstance () in
the JavaDocs).
Ben Eng wrote:
Due to JDOQL's limitations (inability to express joins, when relationships
are not modeled as object references), I find myself needing to drop down to
expressing some queries in SQL through JDBC. However, I still want my Java
code to remain independent of the O/R mapping. I would like to be able to
formulate the SQL without hardcoding any knowledge of the relational table
and column names, by using Kodo's metadata. After poking around the Kodo
Javadocs, it appears as though the relevant calls are as follows:
ClassMetaData cmd = ClassMetaData.getInstance(MyPCObject.class, pm);
FieldMetaData fmd = cmd.getDeclaredField( "myField" );
PersistenceManagerFactory pmf = pm.getPersistenceManagerFactory();
JDBCConfiguration conf = (JDBCConfiguration)
((EEPersistenceManagerFactory)pmf).getConfiguration();
ClassResolver resolver = pm.getClassResolver(MyPCObject.class);
Connector connector = new PersistenceManagerConnector(
(PersistenceManagerImpl) pm );
DBDictionary dict = conf.getDictionary( connector );
FieldMapping fm = ClassMapping.getFieldMapping(fmd, conf, resolver, dict);
Column[] cols = fm.getDataColumns();
Does that look about right?
Here's what I'm trying to do:
class Foo
String name; // application identity
String bar; // foreign key to Bar
class Bar
String name; // application identity
int weight;
Let's say I want to query for all Foo instances for which its bar.weight >
100. Clearly this is trivial to do in JDOQL, if Foo.bar is an object
reference to Bar. But there are frequently good reasons for modeling
relationships as above, for example when Foo and Bar are DTOs exposed by the
remote interface of an EJB. (Yeah, yeah, I'm lazy, using my
PersistenceCapable classes as both the DAOs and the DTOs.) But I still want
to do queries that navigate the relationship; it would be nice to do it in
JDOQL directly. I will also want to do other weird-ass queries that would
definitely only be expressible in SQL. Hence, I'll need Kodo's O/R mapping
metadata.
Is there anything terribly flawed with this logic?
Ben
Steve Kim
[email protected]
SolarMetric Inc.
http://www.solarmetric.com

Using SQL in Query in 3.0.0

I'm very happy to see this feature added to 3.0.0 along with methodQL. This
should alleviate a lot of the issues with trying to use only JDOQL,
especially when the desired SQL statemetn is well understood. Thanks for
adding this!
Ben

Marc,
Calling pm.flush() explicitly doesn't help. Calling
query.setIgnoreCache(true) does work, so that's good.
I even get the correct number of rows back in the Collection. Unfortunately
every item in the Collection is null. I definitely did a
query.setClass(DSChannelValueImpl.class) and it is enhanced properly,
because that's how the table got populated earlier in the test. I am doing a
SELECT *, so the class indicator and pk should be there. I'm assuming it
doesn't mind me aliasing the FROM table name, since I need to disambiguate
it to do a join (below).
Ben
"Marc Prud'hommeaux" <[email protected]> wrote in message
news:[email protected]...
Ben-
I've made a bug report for this:
http://bugzilla.solarmetric.com/show_bug.cgi?id=780
In the meantime, a nicer workaround will probably be to just call
setIgnoreCache(true) on the Query.
In article <[email protected]>, Marc Prud'hommeaux wrote:
Ben-
A potential (but, admittedly, not very nice) workaround for this for the
time being might be to enable NonTransactionalRead=true, and ensure that
there is not a transaction running at the time of query execution.
In article <[email protected]>, Patrick Linskey wrote:
Well, sounds like a bug. We'll take a look. Sorry about that.
What happens if you explicitly flush the PM before execution?
-Patrick
Ben Eng wrote:
Query query = pm.newQuery( "kodo.jdbc.SQL", null );
query.setClass( ChannelValue.class );
query.declareParameters( "VARCHAR pConn, DATETIME pStart,
DATETIME pEnd" );
String filter = "select * from dschannel as c" +
" left join channelsegment as s" +
" on c.pk = s.channel and" +
" c.supporting = pConn and" +
" (s.validForEnd > pStart or" +
" s.validForStart < pEnd)" +
" where s.channel is null";
query.setFilter( filter );
Collection resultSet = (Collection) this.query.execute(
connection, start, end );
This is being called from a method of a stateless session bean that is
only
performing this query. CMT, Required, and the client is not definingits own
transaction boundaries. Therefore, I would not expect anything to bedirtied
in this transaction. This is with the BEA WLS 7.0 appserver.
Ben
"Patrick Linskey" <[email protected]> wrote in message
news:[email protected]...
Ben,
Can you post the code that you're using to create the query?
-Patrick
Ben Eng wrote:
I just ran into a snag with this feature.
kodo.util.UnsupportedOptionException: kodo.jdbc.SQL language queries
cannot
be executed in-memory. Either set the javax.jdo.option.IgnoreCacheproperty
to true, set the kodo.FlushBeforeQueries property to true, or executethe
query before modifying objects within the transaction.
at
kodo.jdbc.query.SQLQuery.newInMemoryQueryExecutor(SQLQuery.java:117)
at kodo.query.AbstractQuery.internalCompile(AbstractQuery.java:545)
atkodo.query.AbstractQuery.getAccessPathMetaDatas(AbstractQuery.java:938)
>>>>
atkodo.query.AbstractQuery.isAccessPathDirty(AbstractQuery.java:745)
at kodo.query.AbstractQuery.executeWithMap(AbstractQuery.java:672)
at kodo.query.AbstractQuery.executeWithArray(AbstractQuery.java:640)
at kodo.query.AbstractQuery.execute(AbstractQuery.java:622)
at
com.metasolv.resources.queries.ChannelAvailabilityQueryBean.execute(ChannelA
>>>>
vailabilityQueryBean.java:84)
at
com.metasolv.oss.inventory.InventorySessionBean.queryInventory(InventorySess
>>>>
ionBean.java:1504)
Oddly, my ra.xml already has the following properties set.
<config-property>
<description>If false, then the JDO implementation mustconsider
modifications, deletions, and additions in the PersistenceManager
transaction cache when executing a query inside a transaction. Else,the
implementation is free to ignore the cache and execute the querydirectly
against the data store.</description>
<config-property-name>IgnoreCache</config-property-name>
<config-property-type>java.lang.Boolean</config-property-type>
<config-property-value>true</config-property-value>
</config-property>
<config-property>
<description>Whether or not Kodo should automatically flush
modifications to the data store before executingqueries.</description>
>>>>>>
<config-property-name>FlushBeforeQueries</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value>true</config-property-value>
</config-property>
I also tried explicitly calling ((KodoPersistenceManager)pm).flush()before
newQuery to no avail. I am at a loss how to get the Query to NOT
execute
in-memory.
Ben
"Ben Eng" <[email protected]> wrote in message
news:[email protected]...
I'm very happy to see this feature added to 3.0.0 along with
methodQL.
>>>>>>
This
should alleviate a lot of the issues with trying to use only JDOQL,
especially when the desired SQL statemetn is well understood. Thanks
for
adding this!--
Marc Prud'hommeaux [email protected]
SolarMetric Inc. http://www.solarmetric.com

JDOQL- (Kodo)SQL

Similar Messages

Maybe you are looking for