What's the best way to write a JDOQL query to compare dates that doesn't give a warning about using a transient as parameter in query?

Page bloom

UPDATE: Turns out this was a problem with another parameter, not the date parameter, which was in fact a transient persistable class. I had left this other parameter out of the example, assuming the date parameter was the issue :) Date comparisons work fine in JDOQL/DataNucleus right out of the box!

What's the best way to compare a date attribute of a PC with a specified Date object (which isn't persistent) without getting this warning:
[WARN ] 13:17:01.397 Query - Attempt to use transient object as parameter in query. Not supported, so using NULL for parameter value
This is a bit of a construed example but here goes...
class Loaned
    Date date;      // java.util.Date - date the Book was loaned on
class Book
      Loaned loaned;
So to find all Books loaned before a given date  
Collection<Book> findBooksLoanedBefore(Date date)
    PersistenceManager pm = getPm();
    Query q = pm.newQuery(Book.class);
    q.setFilter("loaned.date <= :date");
    return new JDOQueryResultCollection(q, q.execute(date));
Perhaps persistent Date objects attributes of a PC can't be compared with a transient Date object like this.
If not, what's the best way to perform a date comparison that takes advantage of the DB's indexing - I don't want to have to do an in memory comparison because there could be millions of objects.
Is the best way to store dates as long's (eg., the result of Date.getTime() ) and then to all comparisons as simple maths comparisons?
In this case we'd pass in date.getTime() as the parameter to the query.
That seems a bit primitive/low level - I would hope there's a higher level way of achieving this without resorting to storing and comparing ints.


The best way to not get a message about passing in a transient persistable object is not to pass in a transient persistable object.
Doing what you say above about passing a Date (which is not a persistable object) does not result in such a warning ... for me.

Page bloom

Ah, Doh! I was looking at the wrong parameter. I had assumed it was the Date parameter causing the trouble but it was another seemingly innocent parameter we had been passing into the query - not shown above in the 'cut down' version of the query.

Not sure how the full query in question in the app ever worked .... hmmmm. I think it was only used for some data migrations that never went ahead so that probably explains how it "not working" was not a problem in the app.