db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: Feature proposal for JDO 2.1 maintenance: current DB time
Date Sat, 23 Dec 2006 01:46:31 GMT
Hi Christiaan,

On Dec 22, 2006, at 5:17 AM, Christiaan des Bouvrie wrote:

> Hi,
> I just want to add my vote for such a feature. I currently use direct
> sql in order to deal with the server date, so a JDO solution would be
> nice.
> Based on the previous discussions, my suggestions:
> -          In order to avoid confusion why not stress more that the
> server date is returned: serverDate();
> -          I would prefer if it is accessible through a method call. I
> have some doubt however whether JDOHelper is the right place, since
> currently JDOHelper has methods for state interrogation of persistent
> objects (from a user point of view this does not require a  
> connection to
> the datastore). To me it would make more sense to add it to
> PersistenceManager. This is basically also the difference in
> JDOHelper.getObjectID() and PersistenceManager.getObjectByID();

I think you are right. It belongs not in a JDOHelper but associated  
with the back end server, which means either the  
PersistenceManagerFactory or PersistenceManager. Since there is a  
requirement that you get the result from the back end, which means  
that you need to have a connection to it, the PersistenceManager  
would seem to be the right interface to use.
> -          I think serverDate() should return java.util.Date since  
> this
> type is already supported by JDO.

There are a lot of types that might make sense. The reason I don't  
like Date is that there is not a good representation of the time  
zone. There is some crosstalk between Date and Calendar but getting  
the server's time zone is problematic.

> I think introducing serverTimeStamp()
> could cause confusion since that would introduce dependency on the
> java.sql.TimeStamp class, making JDO less datastore / sql independent.

Yes, I agree that Timestamp isn't ideal either.

I think that Calendar solves both of these problems. Something like  
java.util.Calendar PersistenceManager.getServerCalendar() would do  
it. The Calendar includes time zone, locale, and Date all wrapped up  
together. You can get a TimeZone by asking getTimeZone() and get the  
Date with getTime().

> To do it similar like the System class, why not introduce
> PersistenceManager.serverNanoTime()  which translates the datastore
> TimeStamp to nano seconds;
> -          It would be nice to use the serverDate() method in JDOQL as
> well, though for me retrieving the server Date and using that instance
> in JDOQL to perform queries would suffice as well;

I was thinking that this would not quite be sufficient for e.g.  
finding Employees whose hire date was within two days. I think that  
SQL supports this functionality but JDOQL does not.

> Kind regards,
> Christiaan

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!

View raw message