Re: Feature proposal for JDO 2.1 maintenance: current DB time

Mon, 23 Oct 2006 12:01:56 -0700

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 <[EMAIL PROTECTED]>:

  
--matthew

    
-----Original Message-----
From: Erik Bengtson [mailto:[EMAIL PROTECTED]]
Sent: Friday, October 20, 2006 12:07 PM
To: [email protected]; [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: [email protected]
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; [email protected]
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

Reply via email to