Good to know. The point that I made on the conf call was that "JDOHelper.getDate()" in JDOQL would be inconsistent with the actual API. Java's Date.getDate() returns an int in the range 1-31.
It's for that reason that I'm advocating a JDOQL function instead. I propose date() & DATE() for this. --matthew >-----Original Message----- >From: Erik Bengtson [mailto:[EMAIL PROTECTED] >Sent: Friday, October 20, 2006 12:07 PM >To: jdo-dev@db.apache.org; [EMAIL PROTECTED] >Subject: RE: Feature proposal for JDO 2.1 maintenance: current DB time > >> I don't think that aligning with JPOX's JDOQL extensions is >a goal of the >> spec. :) > >We can always try :) > >I'm happy with any expression, date(), currentDate(), Date.getDate(), >JDOHelper.getDate(), etc. > > >Quoting Matthew Adams <[EMAIL PROTECTED]>: > >> 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 >> >> >> >> >> > >> > >> > >> > >> > > > >
