You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Fedor Karpelevitch <fe...@Barra.COM> on 2001/08/31 21:27:56 UTC
[PATCH] small patches to torque in 2.1
Hi!
these are small patches to torque in jakarta-turbine-2. Here is the
description of the changes:
1) implemented Gonzalo's suggestion to use JDBC escapes for dates. Seems to
work well and solves all the inherent problems with dates.
2) reverted my change to DateKey.toString() - it was an attempt to solve the
problem above, but did not work out very well. With the fix above it is no
longer needed, and it was causing inconsistent behaviour - toString()
results were different depending on the history of the DateKey.
3) added save(String) and save(DBConnection) methods to Persistent interface
so that it is enough to cast an object to Persistent to use those methods.
someone please commit it.
porting efforts are welcome as usual.
thanks.
fedor.
-------------------------------
The Joy of CVS
Re: [PATCH] small patches to torque in 2.1
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Fedor Karpelevitch <fe...@apache.org> writes:
> On 1 September 2001 09:27, you wrote:
> > Fedor Karpelevitch <fe...@Barra.COM> writes:
> > > 1) implemented Gonzalo's suggestion to use JDBC escapes for dates. Seems
> > > to work well and solves all the inherent problems with dates.
> >
> > Forward ported to jakarta-turbine-3 into SqlExpression and DB.
> > SqlExpression relies on DB to do the formatting, so I slapped the
> > escape in as the default formatting mechanism (i.e. the toDateString()
> > method).
>
> I do not think toDateString() is needed at all since JDBC escape should work
> fine for *any* database. I think it can be dropped (deprecated first).
The only use case which I can think of for it is to handle JDBC
drivers which don't implement JDBC escapes. John, I believe that's
your method--comments?
Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: [PATCH] small patches to torque in 2.1
Posted by Fedor Karpelevitch <fe...@apache.org>.
On 1 September 2001 09:27, you wrote:
> Fedor Karpelevitch <fe...@Barra.COM> writes:
> > 1) implemented Gonzalo's suggestion to use JDBC escapes for dates. Seems
> > to work well and solves all the inherent problems with dates.
>
> Forward ported to jakarta-turbine-3 into SqlExpression and DB.
> SqlExpression relies on DB to do the formatting, so I slapped the
> escape in as the default formatting mechanism (i.e. the toDateString()
> method).
I do not think toDateString() is needed at all since JDBC escape should work
fine for *any* database. I think it can be dropped (deprecated first).
fedor.
>
> John, if you have a moment to look over this change, I'd appreciate
> it.
>
> > 2) reverted my change to DateKey.toString() - it was an attempt to solve
> > the problem above, but did not work out very well. With the fix above it
> > is no longer needed, and it was causing inconsistent behaviour -
> > toString() results were different depending on the history of the
> > DateKey.
>
> Ported.
thanks.
>
> > 3) added save(String) and save(DBConnection) methods to Persistent
> > interface so that it is enough to cast an object to Persistent to use
> > those methods.
>
> Ported. Torque-generated OMs implment these methods.
thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: [PATCH] small patches to torque in 2.1
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Fedor Karpelevitch <fe...@Barra.COM> writes:
> 1) implemented Gonzalo's suggestion to use JDBC escapes for dates. Seems to
> work well and solves all the inherent problems with dates.
Forward ported to jakarta-turbine-3 into SqlExpression and DB.
SqlExpression relies on DB to do the formatting, so I slapped the
escape in as the default formatting mechanism (i.e. the toDateString()
method).
John, if you have a moment to look over this change, I'd appreciate
it.
> 2) reverted my change to DateKey.toString() - it was an attempt to solve the
> problem above, but did not work out very well. With the fix above it is no
> longer needed, and it was causing inconsistent behaviour - toString()
> results were different depending on the history of the DateKey.
Ported.
> 3) added save(String) and save(DBConnection) methods to Persistent interface
> so that it is enough to cast an object to Persistent to use those methods.
Ported. Torque-generated OMs implment these methods.
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org