> 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.
Makes sense. Another contrainst to consider is that some DBs will have dates including timezones and others dont, the behavior on comparisons should be unspecified and may differ from db to db. Quoting Matthew Adams <[EMAIL PROTECTED]>: > > --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 > >> >> > >> >> > >> > > >> > > >> > > >> > > >> > > > > > > > > >
