|
|
|
Sylvie, just to confirm this (again), you are using Castor 0.9.5.3 ? If that's
the case, can you please try to download the 0.9.6. release candidate, and let me know whether your problem still persists ? So far, I have not been able to reproduce your problem with the 0.9.6 RC. If you really considered running your test case with 0.9.6, please bear in mind
that you'll have to amend your database.xml file to cater for a new grammar. What used to be <database ...> now becomes <jdo-conf> I've reproduced the problem with 0.9.6 RC.
This query is ok : This query seems to retrieve nothing : You can try with the test case I've post. >This query seems to retrieve nothing :
>OQLQuery query = db.getOQLQuery("select account.ref from test.testJdo.Account >account where description = $1 "); Sylvie, I'd actually consider this OQL query as invalid. Castor is an O/R mapping tool, and as such does not support projection to object attributes. I hope I did'nt understand you well ?!?
Castor supports this kind of Oql query : But these queries doesn't work on a just created object ... Sorry, Sylvie, my fault. Just forget my last comment.
It actually looks like we really have a problem here. As Sylvie uses a
projection (i.e. restricts her query to just one field of the complete object), SimpleQueryExecutor is used rather than the normal procedure (that uses the complete persistence framework). As such, we just execute a SQL query against the database without checking whether we have an object already associated with the current transaction context. To be honest, as it stands right now, I have no suggestions to make with regards Sylvie, can't you simply load the complete object in question (without selecting Iow, if you changed
OQLQuery query = db.getOQLQuery("select account.ref from test.testJdo.Account to OQLQuery query = db.getOQLQuery("select account from test.testJdo.Account things should work as designed. After having loaded the Account object, you account.getRef(); In fact, at the beginning of the problem, here's the query I need to execute :
"SELECT max(ligne.numeroLigne) FROM And it's to try to find the real problem that I made this query : I solved the first problem by an OQL pass-thru query But I can't be sure the developpers will use this query or another ... What does everybody else think about this ? To be honest, I am tempted to
provide a 'indicator' method on OQLQuery to indicate that e.g. the SimpleQueryExecutor should be executed rather than using the full persistence framework. Of course, things would be packaged and sold differently ... ![]() I've seen a similar feature on JDO, so why not educate the user that (s)he has a choice here ? What about an additional method Database.getSimpleOQLQuery(String oql) nearby
the existing Database.getOQLQuery(String oql) ? This alternate method would allow to create queries, which are executed using SimpleQueryExecutor. One option, but I'd rather provide a boolean flag on an existing method, i.e.
getOQLQuery (String oql, boolean simple) and make getOQLQuery (String oql) call getOQLQuery (String oql, boolean simple) with a I am just trying to refactor the code to accommodate the new method described
above. Problem is that when forcing OQLQuery to execute in 'complete' mode, one will have to alter the OQL query to return full object instances. I just wonder whether this is the right road to follow ? I don't like the idea of adding another method to Database or OQLQuery that we
may have to deprecate again or need to support further with bug 1181 getting solved. As far as I can see at the moment, the value returned from OQLQuery.execute() have to change from QueryResults to Object because a query can also return e.g Integer or a List of Strings. Ok, this needs not to be discussed here. The main problem for sylvie seams to be, that SimpleQueryExecuter doesn't What I still don't understand about this whole thread:
Sylvie claims in Comment #14 to have worked around his problem using an "OQL pass-thru query". This queries directly the current database content, just as using a OQL query with projection (and this way using SimpleQueryExecuter). Neither of both queries looks into the Castor object cache containing not-yet committed JDO objects. So how could extending SimpleQueryExecuter to execute within the current transaction be a solution for Sylvie's problem? Sylvie: Are you really sure, using the "CALL SQL" queries does what you expected and you can see just created objects of the current Castor transaction? Martin, I only had a quick look into OQLQuery and SimpleQueryExecuter. It
seams to me as if OQLQuery executes both OQL and CALL SQL queries within the transaction and SimpleQueryExecuter executes without taking care on transactions. I further assumed that a change to an object has been passed to the database OK, the problem is that SimpleQueryExecutor creates another database session to
execute the query: It's the DatabaseRegistry.createConnection() call in SimpleQueryExecutor.execute(). I wrote a small test program and debugged the SimpleQueryExecutor. What do you think about the following patch? It moves the SimpleQueryExecutor execution into the current database session and transaction. Created an attachment (id=811)
proposed patch Changing JDO attributes is even another case: If you change objects in memory,
you don't see them in the database until you call commit(). Neither CALL SQL queries, nor simple queries will see them (with or without this patch). Only OQL queries will return the already loaded objects with their changes. What's addressed by this big is only the case about newly create()ed objects. Those are INSERTed immediately into the database while executing the create() call. > Neither CALL SQL queries, nor simple queries will see them (with
> or without this patch). Only OQL queries will return the already > loaded objects with their changes. And that's by design, unless I am wrong. Looking at this, I think this is ready to be committed. Objections ? Patch applied. Sylvie, can you please get the latest sources from the CVS
repository, build Castor yourself and see whether it resolves your problem ? If that's not an option, you might want to download the 'daily build'. |
Persistent object
File for JUnit test