db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wes Biggs <...@tralfamadore.com>
Subject Re: Feature proposal for JDO 2.1 maintenance: current DB time
Date Tue, 24 Oct 2006 13:28:28 GMT
For what it's worth, JPA defines

CURRENT_DATE
CURRENT_TIME
CURRENT_TIMESTAMP

all of which return datetime.

I don't really like these as they're very relational.  But I think there 
may be confusion (as Matthew notes) if the function is getDate() -- does 
it return a date, day of month, timestamp (and if so, with which 
portions zeroed), or what?

I'm also not fond of "new Date()" or "System.currentTimeMillis()", 
because I don't know if it will be clear to the user *when* these 
statements will be executed.

I could probably live with something like "currentTimestamp()".

Wes

Jörg von Frantzius wrote:
> Just to add one more to the list of undecidable possibilities: how 
> about "System.currentTimeMillis()"? That would be similar to what you 
> can use in Java, and it is fairly self-explanatory.
>
> Not sure whether the result being a long makes this a handy candidate, 
> but maybe there is some easy way to convert this to a Timestamp or 
> Date object that I don't know off the top of my head...
>
> Regards,
> Jörg
>
> Erik Bengtson schrieb:
>>> 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 <matthew.adams@xcalia.com>:
>>
>>   
>>> --matthew
>>>
>>>     
>>>> -----Original Message-----
>>>> From: Erik Bengtson [mailto:erik@jpox.org]
>>>> Sent: Friday, October 20, 2006 12:07 PM
>>>> To: jdo-dev@db.apache.org; jdo-experts-ext@sun.com
>>>> 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 <matthew.adams@xcalia.com>:
>>>>
>>>>       
>>>>> 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:erik@jpox.org]
>>>>>> Sent: Friday, October 20, 2006 11:42 AM
>>>>>> To: jdo-dev@db.apache.org
>>>>>> Cc: jdo-experts-ext@sun.com
>>>>>> 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 <mbo.tech@spree.de>:
>>>>>>
>>>>>>           
>>>>>>> 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:sun2bin@yahoo.com]
>>>>>>>>> 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 <mbo.tech@spree.de> 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
>>>>>>>>>>>
>>>>>>>>>>>                     
>>>>>>>>>> <joerg.von.frantzius@artnology.com>:
>>>>>>>>>>
>>>>>>>>>>                   
>>>>>>>>>>>                     
>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>                         
     
>>>>>>>>>> <joerg.von.frantzius@artnology.com>:
>>>>>>>>>>
>>>>>>>>>>                   
>>>>>>>>>>>>>>>>                         
     
>>>>>>>>>>>>>>>>> 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:Craig.Russell@sun.com
>>>>>>>>>>>>>>> P.S. A good JDO? O, Gasp!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                             
>>>>>>>>>>>>> Craig Russell
>>>>>>>>>>>>> Architect, Sun Java Enterprise System
>>>>>>>>>>>>>
>>>>>>>>>>>>>                         
>>>>>>>>>> http://java.sun.com/products/jdo
>>>>>>>>>>
>>>>>>>>>>                   
>>>>>>>>>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>>>>>>>>>> P.S. A good JDO? O, Gasp!
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                         
>>>>>>>>>>>>                       
>>>>>>>>>>>                     
>>>>>>>>>> --
>>>>>>>>>> Michael Bouschen		Tech@Spree Engineering GmbH
>>>>>>>>>> mailto:mbo.tech@spree.de	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		Tech@Spree Engineering GmbH
>>>>>>> mailto:mbo.tech@spree.de	http://www.tech.spree.de/
>>>>>>> Tel.:++49/30/235 520-33		Buelowstr. 66
>>>>>>> Fax.:++49/30/2175 2012		D-10783 Berlin
>>>>>>>
>>>>>>>
>>>>>>>             
>>>>>>
>>>>>>           
>>>>
>>>>       
>>
>>
>>
>>
>>
>>   
>


Mime
View raw message