ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Slate <jsl...@mtl.mit.edu>
Subject Re: passing in java date
Date Fri, 22 Aug 2008 14:40:48 GMT
Hi Chris, thanks for the idea but the problem is that the time on the DB 
is not exactly the same as the time on the Web server. So if you do 
something like this:

INSERT INTO foo (create_time, value) values (#currentTime#, 'bar');
SELECT * FROM foo WHERE create_time <= CURRENT_TIME; --like sysdate for 

The select returns no results. The obvious solution seemed to be to use 
time from the same source, i.e. change the first statement to use 
CURRENT_TIME or the second to use #currentTime#. Since we might not 
always be dealing with the current time, I'd rather do the latter, so I 
can be working with Java dates.

I wonder, do other people rely on the times being perfectly synched? Or 
always use the DB time?

BTW, if there were notes on setting up a proxy for an SQL client map, it 
might be useful for cases other than just this one.


Chris O'Connell wrote:
> Sorry if this seems too simplistic, but why don't you let the database
> server worry about it?  You would do something like:
> Update table set update_date = sysdate;
> Instead of:
> Update table set update_Date = #currentTime#
> -----Original Message-----
> From: Jonathan Slate [mailto:jslate@mtl.mit.edu] 
> Sent: Friday, August 22, 2008 9:04 AM
> To: user-java@ibatis.apache.org
> Subject: Re: passing in java date
> Okay, I'll take the lack of response to mean that there isn't much 
> interest in this, I'll just change my code to pass in the date every time.
> Jonathan Slate wrote:
>> Okay, so you mean and AOP proxy, right? Thanks for the suggestion. It 
>> doesn't seem like that's documented much, looking at the mailing list 
>> archives I'm guessing my best bet would be to download the iBATIS 
>> source and see how you guys are doing the logging stuff, right?
>> I don't know, I'm guessing this is going to be more work than it is 
>> worth for me in the long run. But if there are some decent examples 
>> maybe I'll give it a try, or would it be helpful if I did it and wrote 
>> it up for others? Not sure if this is something other people would need.
>> If I *did* do this, would it make more sense to pass in the date as 
>> part of the parameterObject or as a property? It looks like the 
>> properties (java.util.Properties) get passed to the 
>> SqlMapClientBuilder which builds the SqlMapClient, so I'm thinking 
>> that once the SqlMapClient is built, those properties are essentially 
>> unmodifiable.
>> Or I could do before advice for all the methods that take a 
>> parameterObject to create a map, setting a "currentTime" value and... 
>> hm... "parameterObject" value? ...well, I think I'd have some things 
>> to work out there.
>> Maybe I'm missing something obvious here. :)
>> Thanks again,
>> Jonathan
>> Larry Meadors wrote:
>>> Put a proxy on the sql map client interface.
>>> Larry
>>> On Thu, Aug 21, 2008 at 6:57 AM, Jonathan Slate <jslate@mtl.mit.edu> 
>>> wrote:
>>>> Hi:
>>>> We were having some problems where the time on the Web server and 
>>>> the DB
>>>> server are off by a few milliseconds and it was causing some issues, so
>>>> rather than rely on getting the times synched perfectly, I thought 
>>>> we could
>>>> just always use the time on the Web server by passing in the current 
>>>> time
>>>> when querying.
>>>> I could change all of our "getSqlMapClientTemplate()..." calls to 
>>>> pass in a
>>>> map that includes the current java date/time, but that would be a 
>>>> lot of
>>>> work (and I'm lazy). So I was trying to find a way to always make "now"
>>>> available  to my SQL maps.
>>>> For example:
>>>> SELECT * FROM foo WHERE start_time <= ${now}
>>>> I know I can use static properties from a properties file like this. Is
>>>> there a way to do this for something more dynamic like "current time?"
>>>> Thanks,
>>>> Jonathan
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com 
> Version: 8.0.138 / Virus Database: 270.6.6/1627 - Release Date: 8/22/2008
> 6:48 AM

View raw message