|
Home > Archive > Apache JDO Project > December 2006 > Feature proposal for JDO 2.1 maintenance: current DB time
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Feature proposal for JDO 2.1 maintenance: current DB time
|
|
| Jörg von Frantzius 2006-10-16, 7:11 am |
| 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
| |
| Erik Bengtson 2006-10-16, 7:11 pm |
| +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 L Russell 2006-10-16, 7:11 pm |
| | |
| Jörg von Frantzius 2006-10-19, 7:11 am |
| 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:
>
>
> 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 L Russell 2006-10-19, 1:11 pm |
| | |
| Jörg von Frantzius 2006-10-19, 1:11 pm |
| 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:
>
>
> 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!
>
| |
| Erik Bengtson 2006-10-19, 7:11 pm |
| 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:
>
>
| |
| Michael Bouschen 2006-10-19, 7:11 pm |
| 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>:
>
>
>
>
>
--
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
| |
| Bin Sun 2006-10-20, 7:11 am |
| Hi, all!
I think to least impact the current API, we'd
better simply add a method to PMF or PM:
public Date getNow();
--- 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
> the client. A 2nd requirement
> startDate > new Date()");
> <joerg.von.frantzius@artnology.com>:
> want to see, but here's
> query.setResultClass(java.sql.Timestamp.class);
> updated object's
> still having a bit of
> case you describe
> new Date() in action.
> wrote:
> requirements. Once we are
> use it e.g. for
> being evaluated on the
> back end. And being
> bound candidateCollection.
> you have a Date in
> wrote:
> expression where evaluation
> <joerg.von.frantzius@artnology.com>:
> our applications we had to
> time(-stamp). In one
> messages with visibility of
> for our simple replication
> often crucial for
> source of time information
> of doing that
> http://java.sun.com/products/jdo
> http://java.sun.com/products/jdo
>
>
> --
> 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
| |
| Bin Sun 2006-10-20, 7:11 am |
| 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
> the client. A 2nd requirement
> startDate > new Date()");
> <joerg.von.frantzius@artnology.com>:
> want to see, but here's
> query.setResultClass(java.sql.Timestamp.class);
> updated object's
> still having a bit of
> case you describe
> new Date() in action.
> wrote:
> requirements. Once we are
> use it e.g. for
> being evaluated on the
> back end. And being
> bound candidateCollection.
> you have a Date in
> wrote:
> expression where evaluation
> <joerg.von.frantzius@artnology.com>:
> our applications we had to
> time(-stamp). In one
> messages with visibility of
> for our simple replication
> often crucial for
> source of time information
> of doing that
> http://java.sun.com/products/jdo
> http://java.sun.com/products/jdo
>
>
> --
> 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
| |
| Matthew Adams 2006-10-20, 1:11 pm |
| 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]=20
>Sent: Friday, October 20, 2006 1:59 AM
>To: Michael Bouschen; jdo-dev@db.apache.org
>Cc: J=F6rg" 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:
>
>
>
> ________________________________________
__________
>Do You Yahoo!?
>Tired of spam? Yahoo! Mail has the best spam protection around=20
>http://mail.yahoo.com=20
>
| |
| Michael Bouschen 2006-10-20, 1:11 pm |
| 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 r
eturn 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 d
atastore 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 th
e 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 datet
ime's resolution remains for this method.[vbcol=seagreen]
>
> --matthew
>
>
--
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
| |
| Erik Bengtson 2006-10-20, 7:11 pm |
| 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
> 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).
> 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.
>
>
> --
> 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
>
>
| |
| Matthew Adams 2006-10-20, 7:11 pm |
| 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]=20
>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.=20
>Methods unrelated
>to management of PCs lying in PM does not sound good to me,=20
>but currentDate in
>particular fits very well in JDOQL.
>
>JPOX has several additional JDOQL functions. Similar to=20
>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>:
>
>cleaner solution
>this, similar to
>leave unspecified
>for this purpose,
>getCurrentDate()". It could be
>this functionality,
>specifying that the
>datastore didn't
>to the caller. It
>enough from the
>unreliable. The
>current DB time
>
>
>
>
| |
| Erik Bengtson 2006-10-20, 7:11 pm |
| > 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
>
>
| |
| Matthew Adams 2006-10-20, 7:11 pm |
| 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.=20
It's for that reason that I'm advocating a JDOQL function instead. I =
propose date() & DATE() for this.
--matthew
>-----Original Message-----
>From: Erik Bengtson [mailto:erik@jpox.org]=20
>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
>
>a goal of the
>
>We can always try
>
>I'm happy with any expression, date(), currentDate(), Date.getDate(),
>JDOHelper.getDate(), etc.
>
>
>Quoting Matthew Adams <matthew.adams@xcalia.com>:
>
>a goal of the
>Date's getDate()
>deprecated in
>but we know that
>to avg, count,
>would recommend
>current DB time
>methods.
>unresolved.
>tenth of second,
>placed on
>answer to that
>
>
>
>
| |
| Erik Bengtson 2006-10-20, 7:11 pm |
| > 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
>
>
| |
| Craig L Russell 2006-10-21, 1:11 am |
| | |
| Jörg von Frantzius 2006-10-23, 7:11 pm |
| 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:
>
> 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>:
>
>
>
>
>
>
>
>
| |
| Wes Biggs 2006-10-24, 1:11 pm |
| 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:
>
| |
| Christiaan des Bouvrie 2006-12-22, 1:11 pm |
| 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 serverDate() should return java.util.Date since this
type is already supported by JDO. I think introducing serverTimeStamp()
could cause confusion since that would introduce dependency on the
java.sql.TimeStamp class, making JDO less datastore / sql independent.
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;
Kind regards,
Christiaan
| |
| Craig L Russell 2006-12-23, 1:11 am |
| |
|
|
|
|