> 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 > >> > >> > > > > > > > > >
