Hi Erik, I don't think that aligning with JPOX's JDOQL extensions is a goal of the spec. :)
While Date has methods like getDay(), getMonth(), etc., and Date's getDate() method returns the day of the month between 1 & 31 (and is deprecated in favor of Calendar.get(Calendar.DAY_OF_MONTH)). The only native syntax in Java to do this is "new Date()", but we know that might have problems with JDOQL's constructor syntax. This is why I recommended the standalone function currentDate(), similar to avg, count, etc. To align with upper and lower casing conventions, I guess I would recommend "date()" and "DATE()" to avoid the camel casing. --matthew >-----Original Message----- >From: Erik Bengtson [mailto:[EMAIL PROTECTED] >Sent: Friday, October 20, 2006 11:42 AM >To: jdo-dev@db.apache.org >Cc: [EMAIL PROTECTED] >Subject: Re: Feature proposal for JDO 2.1 maintenance: current DB time > >Hi, > >I like the currentDate() and dislike adding methods to the PM. >Methods unrelated >to management of PCs lying in PM does not sound good to me, >but currentDate in >particular fits very well in JDOQL. > >JPOX has several additional JDOQL functions. Similar to >currentDate(), we have >Date.getDay(), Date.getMonth(), etc... >http://www.jpox.org/docs/1_1/query_jdoql_methods.html > >I would propose Date.getDate() which aligns to JPOX JDOQL methods. :) > >Regards, > >Quoting Michael Bouschen <[EMAIL PROTECTED]>: > >> Hi, >> >> another alternative is making it a keyword, so something like >> CURRENTDATE or CURRENT_DATE w/o parenthesis. >> >> I agree with leaving the resolution of the return value unresolved. >> >> Regards Michael >> > As we discussed on the Fri conf call today, I think that a >cleaner solution >> is to introduce a new function "currentDate()" to JDOQL for >this, similar to >> JDOQL's count/sum/min/max/avg. Further, I would prefer to >leave unspecified >> the resolution of the return value for this (second, tenth of second, >> millisecond, etc). >> > >> > As for the Bin Sun's proposal to add a method to the API >for this purpose, >> I think that it's interesting. I would prefer that it be placed on >> PersistenceManager with the signature "Date >getCurrentDate()". It could be >> specified that if the underlying datastore cannot support >this functionality, >> the implementation will return null. I considered >specifying that the >> implementation should return "new Date()" in the event the >datastore didn't >> support it, but I think returning null is more informative >to the caller. It >> clearly indicates that the caller just can't know the answer to that >> question, and the JVM's current datetime may be different >enough from the >> underlying database's datetime that using that value may be >unreliable. The >> question of the datetime's resolution remains for this method. >> > >> > --matthew >> > >> > >> >> -----Original Message----- >> >> From: Bin Sun [mailto:[EMAIL PROTECTED] >> >> Sent: Friday, October 20, 2006 1:59 AM >> >> To: Michael Bouschen; jdo-dev@db.apache.org >> >> Cc: Jörg" von Frantzius; JDO Expert Group >> >> Subject: Re: Feature proposal for JDO 2.1 maintenance: >current DB time >> >> >> >> Hi, all! >> >> >> >> I think to least impact the current API, we'd >> >> better simply add a method to PMF or PM: >> >> public Date getNow(); >> >> >> >> Then we can use this Date as a parameter in any >> >> Query. >> >> >> >> --- Michael Bouschen <[EMAIL PROTECTED]> wrote: >> >> >> >> >> >>> Hi, >> >>> >> >>> I see one issue with using the syntax "new Date()": >> >>> it might conflict >> >>> with the constructor expression used in the result >> >>> expression, because >> >>> both use the keyword "new". A constructor expression >> >>> is only supported >> >>> in the query result expression; it is used to wrap >> >>> values into a result >> >>> class element and it is evaluated on the client. The >> >>> expression "new >> >>> Date()" should be supported in the result and the >> >>> filter, it does not >> >>> wrap any other values and it is evaluated on the >> >>> database back end. >> >>> How about using a different syntax for the current >> >>> database date, e.g. >> >>> JDOHelper.CURRENT_DATE() ? >> >>> >> >>> The other interesting issue with the example from >> >>> Jörg is that it does >> >>> not define a candidate class. I think this was on >> >>> purpose, because the >> >>> query should not access any tables in the database, >> >>> but just return the >> >>> current date. Maybe we could use the JDOHelper as >> >>> the candidate class in >> >>> this case? This would be something similar to the >> >>> DUAL table in oracle. >> >>> >> >>> Regards Michael >> >>> >> >>>> Your 1st requirement is to retrieve the date on >> >>>> >> >>> the client. A 2nd requirement >> >>> >> >>>> would be comparisons over database server date. >> >>>> >> >>>> I have one sample for the 2nd requirement >> >>>> >> >>>> Query query = newQuery("select from Person where >> >>>> >> >>> startDate > new Date()"); >> >>> >> >>>> Quoting Jörg von Frantzius >> >>>> >> >>> <[EMAIL PROTECTED]>: >> >>> >> >>>> >> >>>> >> >>>>> Hi Craig, >> >>>>> >> >>>>> I'm not so sure whether this is really what you >> >>>>> >> >>> want to see, but here's >> >>> >> >>>>> something: >> >>>>> >> >>>>> Query query = newQuery("new Date()"); >> >>>>> >> >>>>> >> >>> query.setResultClass(java.sql.Timestamp.class); >> >>> >> >>>>> query.setUnique(true); >> >>>>> Date result = (Date)timeQuery.execute(); >> >>>>> >> >>>>> >> >>>>> That result Date can then be used to e.g. set an >> >>>>> >> >>> updated object's >> >>> >> >>>>> lastModification timestamp before committing it. >> >>>>> >> >>>>> Regards, >> >>>>> Jörg >> >>>>> >> >>>>> Craig L Russell schrieb: >> >>>>> >> >>>>> >> >>>>>> Hi Jörg, >> >>>>>> >> >>>>>> Sorry to exercise you more on this, but I'm >> >>>>>> >> >>> still having a bit of >> >>> >> >>>>>> difficulty seeing how to use this feature. >> >>>>>> >> >>>>>> Could you please give us an example of the use >> >>>>>> >> >>> case you describe >> >>> >> >>>>>> below? I'd like to see the JDOQL query that uses >> >>>>>> >> >>> new Date() in action. >> >>> >> >>>>>> Thanks! >> >>>>>> >> >>>>>> Craig >> >>>>>> >> >>>>>> On Oct 19, 2006, at 1:33 AM, Jörg von Frantzius >> >>>>>> >> >>> wrote: >> >>> >> >>>>>> >> >>>>>> >> >>>>>>> Hello Craig, >> >>>>>>> >> >>>>>>> as far as I can see that does satisfy our >> >>>>>>> >> >>> requirements. Once we are >> >>> >> >>>>>>> able to query for that date in JDOQL, we can >> >>>>>>> >> >>> use it e.g. for >> >>> >> >>>>>>> lastmodification timestamps and the like. >> >>>>>>> >> >>>>>>> Regards, >> >>>>>>> Jörg >> >>>>>>> >> >>>>>>> Craig L Russell schrieb: >> >>>>>>> >> >>>>>>> >> >>>>>>>> It's easy enough to define "new Date()" as >> >>>>>>>> >> >>> being evaluated on the >> >>> >> >>>>>>>> back end for queries that are executed on the >> >>>>>>>> >> >>> back end. And being >> >>> >> >>>>>>>> evaluated in the vm for queries that have a >> >>>>>>>> >> >>> bound candidateCollection. >> >>> >> >>>>>>>> But does this satisfy the requirements? Once >> >>>>>>>> >> >>> you have a Date in >> >>> >> >>>>>>>> JDOQL, what can you do with it? >> >>>>>>>> >> >>>>>>>> Craig >> >>>>>>>> >> >>>>>>>> On Oct 16, 2006, at 11:58 AM, Erik Bengtson >> >>>>>>>> >> >>> wrote: >> >>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>>> +1. maybe "new Date()" could be the >> >>>>>>>>> >> >>> expression where evaluation >> >>> >> >>>>>>>>> occurs on the >> >>>>>>>>> database. >> >>>>>>>>> >> >>>>>>>>> Quoting Jörg von Frantzius >> >>>>>>>>> >> >>> <[EMAIL PROTECTED]>: >> >>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>>> Dear experts, >> >>>>>>>>>> >> >>>>>>>>>> there had been several occasions where in >> >>>>>>>>>> >> >>> our applications we had to >> >>> >> >>>>>>>>>> determine the database server's current >> >>>>>>>>>> >> >>> time(-stamp). In one >> >>> >> >>>>>>>>>> application >> >>>>>>>>>> we needed it to synchronize sent JMS >> >>>>>>>>>> >> >>> messages with visibility of >> >>> >> >>>>>>>>>> commits >> >>>>>>>>>> in the database, and in another we need it >> >>>>>>>>>> >> >>> for our simple replication >> >>> >> >>>>>>>>>> algorithm. >> >>>>>>>>>> >> >>>>>>>>>> In distributed systems in general it is >> >>>>>>>>>> >> >>> often crucial for >> >>> >> >>>>>>>>>> synchronization purposes to have a common >> >>>>>>>>>> >> >>> source of time information >> >>> >> >>>>>>>>>> that is accessible from all processes. >> >>>>>>>>>> >> >>>>>>>>>> It would be great if JDO2 could offer a way >> >>>>>>>>>> >> >>> of doing that >> >>> >> >>>>>>>>>> independently >> >>>>>>>>>> of the database, e.g. as a JDOQL function. >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> Regards, >> >>>>>>>>>> Jörg >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>> Craig Russell >> >>>>>>>> Architect, Sun Java Enterprise System >> >>>>>>>> >> >>> http://java.sun.com/products/jdo >> >>> >> >>>>>>>> 408 276-5638 mailto:[EMAIL PROTECTED] >> >>>>>>>> P.S. A good JDO? O, Gasp! >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>> Craig Russell >> >>>>>> Architect, Sun Java Enterprise System >> >>>>>> >> >>> http://java.sun.com/products/jdo >> >>> >> >>>>>> 408 276-5638 mailto:[EMAIL PROTECTED] >> >>>>>> P.S. A good JDO? O, Gasp! >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>> >> >>>>> >> >>>> >> >>>> >> >>> -- >> >>> Michael Bouschen [EMAIL PROTECTED] Engineering GmbH >> >>> mailto:[EMAIL PROTECTED] http://www.tech.spree.de/ >> >>> Tel.:++49/30/235 520-33 Buelowstr. 66 >> >>> Fax.:++49/30/2175 2012 D-10783 Berlin >> >>> >> >>> >> >>> >> >> __________________________________________________ >> >> Do You Yahoo!? >> >> Tired of spam? Yahoo! Mail has the best spam protection around >> >> http://mail.yahoo.com >> >> >> >> >> >> >> -- >> Michael Bouschen [EMAIL PROTECTED] Engineering GmbH >> mailto:[EMAIL PROTECTED] http://www.tech.spree.de/ >> Tel.:++49/30/235 520-33 Buelowstr. 66 >> Fax.:++49/30/2175 2012 D-10783 Berlin >> >> > > > >
